September 25, 2021

Dedicated Forum to help removing adware, malware, spyware, ransomware, trojans, viruses and more!

How two signatures in a security update for Malwarebytes falsely identified malicious objects

A while back on April the 15th posts began to appear on the Malwarebytes forums regarding issues with the detection of malware. Suddenly it seemed to identify parts of the operating system as well as itself as malware

C:WindowsSystem32SessEnv.dll (Trojan.Downloader.ED) -> No action taken. [2c3c895fbbb0b97dfa37ff68d42fc63a]

C:WindowsSystem32upnphost.dll (Trojan.Downloader.ED) -> No action taken. [f1772bbd0a61f343e64b0463e3206898]

C:WindowsSystem32wcncsvc.dll (Trojan.Downloader.ED) -> No action taken. [35339a4ef07b2b0b6dc48dda8a79b749]

C:WindowsSystem32WebClnt.dll (Trojan.Downloader.ED) -> No action taken. [3a2e0adea3c82016c46d4720f21122de]

C:WindowsSystem32WsmSvc.dll (Trojan.Downloader.ED) -> No action taken. [e7815f897dee56e036fbf374e91af60a]

It even started to detect itself as malware ( a good clue something has gone horribly wrong )

C:Program Files (x86)Malwarebytes’ Anti-Malwarembam.exe (Trojan.Downloader.ED) -> No action taken. [0365915779f2d16560d1a6c139cabf41]

C:Program Files (x86)Malwarebytes’ Anti-Malwarembamscheduler.exe (Trojan.Downloader.ED) -> No action taken. [d29647a1b2b9b18573be363108fb42be]

C:Program Files (x86)Malwarebytes’ Anti-Malwarembamservice.exe (Trojan.Downloader.ED) -> No action taken. [1e4ad612fc6f0a2c3af7ce9941c2ab55]

As seen in the topic it started to identify running processes, registry entries and files stored on the hard disk.

The developers were quick to put out updates to resolve the issue and even supplied a tool to fix the issues. As posted by Marcin Kleczynski on the Malwarebytes blog it was fixed within minutes:

Within 8 minutes, the update was pulled from our servers.

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. The one from when the bad signatures were added and the fixed definition files published. 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 update that fixed the issue was “v2013.04.15.13” according to a Malwarebytes employee on the forums called “Maurice Naggar”.

Turning on Wireshark gives a rundown of what Malwarebytes does when updating (I made this capture while writing this blogpost). 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 ). All the requests go to “” for the updates. But at the end it does the part I’m interested in, it updates the definition files. It starts off by requesting the latest definition file:

GET /v1/database/rules/version.chk HTTP/1.1

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 ).

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. The request:

GET /v1/database/rules/data/rules.v2013.06.27.09.ref.yaml HTTP/1.1

And the response from the update server:

filename: rules.v2013.06.27.09.ref
  previous: v2013.06.27.08
  current: v2013.06.27.09
date: Thu, 27 Jun 2013 16:32:13 GMT
  size: 6616865
  md5: cc8b2b2ace236d10eb833d9d3b46e23a
  format: legacydb
  size: 26780341
  md5: 318dd700ef1ac0b26b2eb2cf38d90cd4
  format: legacydb
  size: 323

Now in my case it looked like it was doing an incremental update for the day, it did the following requests:

GET /v1/database/rules/data/ HTTP/1.1

But this did give me a binary blob which seemed to be the definitions file.

Side-note, whoever is managing the update servers for Malwarebytes added some extra X forwarded headers to the responses:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=7200
Content-MD5: TtzBRPrw2mTl+UYhEYzMvw==
Content-Type: text/plain
Date: Thu, 27 Jun 2013 16:51:37 GMT
ETag: “8b6-4e02516192100”
Expires: Thu, 27 Jun 2013 18:51:37 GMT
Last-Modified: Thu, 27 Jun 2013 16:16:36 GMT
Server: ECAcc (ams/489A)
x-admin: tedivm was here.
X-Cache: HIT
x-shameless-plug: Looking for a dev job? Send your resume to
Content-Length: 2230
Connection: close

I’m assuming tedivm is the handle of one of the admins, nice touch with the “x-shameless-plug” headers though!

So now we know how it works in terms of getting the updates, but what about the two definition files we want, “v2013.04.15.12” and “v2013.04.15.13”. Well, we can just request them like so:

GET /v1/database/rules/data/rules.v2013.04.15.12.ref HTTP/1.1

GET /v1/database/rules/data/rules.v2013.04.15.13.ref HTTP/1.1

This gives us two binary blobs, one with a size of 6.294.406 bytes, and one with a size of 6.294.350 bytes, not a big change but they did remove something.

There is one issue with these update files… they are encrypted. I will not show you how to decrypt them but after attaching OllyDbg and doing some reversing with the help of a buddy of mine we figured out how to decrypt the files, end of that story. We now ended up with the decrypted files, time for some diff’ing!

VOFFSET=Trojan.Downloader.ED, 74433, 1, 6, 687474703A2F2F36342E36342E32302E35302F32373753457236372E657865, NS
VOFFSET=Trojan.Downloader.ED, 74485, 1, 14 687474703A2F2F6674702E74636D6C732E6F72672F7172415165562E657865, NS

And the description “Trojan.Downloader.ED” is the one described to cause the trouble on the forum posts linked earlier. So how exactly do these rules work, I can’t say for sure that I am 100% correct on this but this is what I’ve got:

  • VOFFSET: Some kind of offset byte matching, whatever is after the equals sign is the description
  • 74433 and 74485 seem to be signature identifiers, SID’s if you will.
  • 1, 6  and 1, 14 seem to be some kind of range, but I’ll get back with that.
  • 687474703A2F2F36342E36342E32302E35302F32373753457236372E657865: Is a byte pattern for hxxp:// which is related to this piece of malware on VT [link]
  • 687474703A2F2F6674702E74636D6C732E6F72672F7172415165562E657865: Is a byte pattern for hxxp:// which is related to a ponyloader malware loader sample [link]
  • NS: No clue what this is for….

What I think happened with these rules are the offsets being incorrect or misinterpreted. The range of 1-6 in the first rule will give “http:” and the other range for 1-14 will give “” if you use those ranges as delimiters for the strings those byte patterns match. My guess is that the “http:” started to match everywhere… maybe the NS is a flag to hint that partial matching is fine, who knows.

I checked some of the files that MBAM started to detect as malware by just using the Linux “strings -el <filename>” and grepped for the “http:” string from the byte pattern. All of the files I got from the logs posted on the forums contained those strings so I’m guessing thats what went wrong.

In the end the Malwarebytes devs fixed the issue within minutes of appearing and provided appropriate tooling to fix the issues caused by this ‘mismatch’ for the less experienced users. The whole mess was caused by just two simple rules within a file that contains around 227.000~ in total, not bad. All testing was done with the free version of Malwarebytes.

It was a fun thing to figure out both the encryption and the actual definition files themselves, I’ve even gone as far as playing around by pushing my own byte patterns in custom rule files just to see if it worked, which it did 😉 Also a big thank you to my sleep deprived buddy for the decryption tool made at 4~ AM, he writes articles on his blog at