Jump to content

Strange Behavior Since Since Buying MBAM Pro


Recommended Posts

WIN 7 x64 SP1, Comodo 5.x Firewall and Defense+ w/sandboxing, Avast 6.X w/o snadboxing, MBAM Pro 1.5x.

Based on my MBAM Pro 1.51 trail and the reviews I have been following over at Malware Research Group on Pro's performance, I purchased two MBAM Pro licenses.

Ever since I registered MBAM using one of my purchased keys, I have seen things I don't like to see. I have received ICMP destination unreachable 3,13 pings where I had none before. Yesterday I noticed that an IP that is listed under RIPE but shows a Santa Monica, CA address and is associated with MBAM updates was listening on a handful of high addresses to http tcp port 80 outbound. These connections showed that they were owned by "system". Outbound "systen" or kernel Internet access is a no-no in my book.

When I ran the free ver. of MBAM, I would see MBAM update connections though a single port to http tcp port 80.

Explaination please.

Link to post
Share on other sites

I have received ICMP destination unreachable 3,13 pings where I had none before.

Are you getting any notifications about blocked IP addresses from our protection module? It is very possible that you're attempting to ping systems which we have blocked for hosting malicious software.

Yesterday I noticed that an IP that is listed under RIPE but shows a Santa Monica, CA address and is associated with MBAM updates was listening on a handful of high addresses to http tcp port 80 outbound.

I'm not sure what you mean by "high addresses", so I'll just explain what network connections you should be seeing. There are basically two groups-

1. Updates occur over port 80 and can be to literally hundreds (if not thousands) of different IP addresses. This is because we push our traffic through Content Distribution Networks- this allows us to distribute the updates globally, and with connections to many different ISPs, so that our users (such as yourself) can get the quickest possible updates. These CDN's are constantly reworking the routes- if machines are down, overloaded or somehow degraded then they'll route to other machines which aren't. We also monitor performance ourselves to let us switch which cdn is active in different regions based on our own experiences.

These updates are very innocuous- the client is simply checking the various files it needs to see if updates are available, and then pulling them down to apply them.

2. Dynamic communications and statistics happen over port 443 (the ssl port). If you have the option for sending anonymous statistics enabled in your preferences then MBAM will send us a list of anything detected during a scan, as well as some very generic information about your system- operating system version, architecture (32 or 64 bit), language that mbam runs- all of this can be turned off by disabling anonymous statistics. MBAM also sends it's version information to us on a regular basis.

This information is vital to making a great product. The version information lets us know when we can retire support for older versions without hurting you guys, while the operating system data lets us know how to deploy resources affectively. The language information, as I'm sure you can guess, is very helpful when we're figuring out new languages to add (we added Vietnamese in the most recent version!).

There are also two special cases of network connections- if you're running a trial or have a registered product then MBAM will occasionally talk to this server to pull down relative information it may need. If you have an active trial then the client checks in with the server to see how long the trial is enabled for, and if the product is registered it checks in with the license.

These connections showed that they were owned by "system". Outbound "systen" or kernel Internet access is a no-no in my book.

I'm not sure why this would be the case, or if these are even our connections. I handle all of the server side stuff, not the client side, so I'll grab someone who can give you a more detailed answer than I could.

When I ran the free ver. of MBAM, I would see MBAM update connections though a single port to http tcp port 80.

We've been utilizing the CDN's for years now, so you'd see different ip addresses during each update. The free version updates in the same way as the paid, and handles statistics in the same way as well, so I don't see why you would notice any differences. We do have limits in how often we connect to the servers, so it is possible that you just didn't see them before. Still, it sounds like something unusual may be happening here, so if you have any more information on this I'd be happy to help narrow down the possible causes.

Link to post
Share on other sites

I just logged on my home PC today and didn't see anything suspicious. I saw the dial-out from svchost.exe to 93.184.xxx.xxx, the Edgecast? servers, for an MBAM update I assume. It did open 8 or so connections from system but they were time-wait status which is what you would expect to see. Now I could have been mistaken with the "listening" status I saw yesterday but I don't think so. They were all to 93.184.215.73. Whois shows that registered to Edgecast via RIPE with a region of Europe. I always get nervous when I see RIPE connections since I am located on the east coast of the U.S.

The ICMP activity started on 6/11 and stopped on 6/14. The IPs were 4.53.2.66, 66.21.240.205, and 68.232.37.39. Now I did find a Trojan on 6/12 which Emissoft Antimalware got rid off. Still don't know where that came from but appears to have happened during that prior week. I was clean prior to that per a full Emmisoft scan which I run manually weekly. This is the second thing Avast let slip through. I am fairly certain I was running MBAM Pro in trial mode during that week. I am theorizing that the ICMPs were from the Trojan handlers looking for their expected home and not finding it?

Anyway, i will keep an eye on things and re-post if I see anything unusual.

BTW - how does MBAM Pro real time protection work? I am looking at my connection using TCPView with IE8 active and I see nothing MBAM related running. Is it running from a svchost.exe task? I see a localhost listening connection - TCP - 10243 from system. Is that MBAM Pro? Avast uses the 12xxxx - TCP - localhost range from what I have seen.

Link to post
Share on other sites

I just logged on my home PC today and didn't see anything suspicious. I saw the dial-out from svchost.exe to 93.184.xxx.xxx, the Edgecast? servers, for an MBAM update I assume. It did open 8 or so connections from system but they were time-wait status which is what you would expect to see. Now I could have been mistaken with the "listening" status I saw yesterday but I don't think so. They were all to 93.184.215.73. Whois shows that registered to Edgecast via RIPE with a region of Europe. I always get nervous when I see RIPE connections since I am located on the east coast of the U.S.

Feel free to post the full IP address. Edgecast is one of our CDN providers. Just because the IP address was registered in RIPE doesn't mean it is located in Europe- as a global company Edgecast subnets their blocks into quite a few different chunks. If you have any issues with slow downloads please send along a traceroute (you can open a ticket with support if you don't want it posted on the forums).

The ICMP activity started on 6/11 and stopped on 6/14. The IPs were 4.53.2.66, 66.21.240.205, and 68.232.37.39. Now I did find a Trojan on 6/12 which Emissoft Antimalware got rid off. Still don't know where that came from but appears to have happened during that prior week. I was clean prior to that per a full Emmisoft scan which I run manually weekly. This is the second thing Avast let slip through. I am fairly certain I was running MBAM Pro in trial mode during that week. I am theorizing that the ICMPs were from the Trojan handlers looking for their expected home and not finding it?

Of the three IP addresses you listed only one of them belongs to us- 68.232.37.39. One of them belongs to L3 (which means it could be issued out for residential or commercial usage elsewhere), while the other looks to be on a residential machine. This is pretty suspicious and it would not surprise me if you were infected with something- you are most likely right about the trojan trying to phone home.

Anyway, i will keep an eye on things and re-post if I see anything unusual.

BTW - how does MBAM Pro real time protection work? I am looking at my connection using TCPView with IE8 active and I see nothing MBAM related running. Is it running from a svchost.exe task? I see a localhost listening connection - TCP - 10243 from system. Is that MBAM Pro? Avast uses the 12xxxx - TCP - localhost range from what I have seen.

I'm going to defer to one of the client side guys on this one as well.

Link to post
Share on other sites

The Protection Module and Scheduler in MBAM PRO are driven by the service mbamservice.exe, which runs as LocalSystem, but it does not "listen" for updates. Realtime protection essentially pings Malwarebytes servers every few minutes checking for a database update, and downloads it as soon as it is available (this is the cleanest way to implement this without setting up a webserver on every client machine!). It will make connections that look like they're coming from a system process, but it shouldn't be "listening".

Can we see the output from netstat -a -b -o ? That might help us figure out whether it's our connection or not.

Link to post
Share on other sites

C:\Windows\system32>netstat -a -b -o

Active Connections

Proto Local Address Foreign Address State

TCP 0.0.0.0:135 Don-PC:0 LISTENING

RpcSs

[svchost.exe]

TCP 0.0.0.0:445 Don-PC:0 LISTENING

Can not obtain ownership information

TCP 0.0.0.0:554 Don-PC:0 LISTENING

[wmpnetwk.exe]

TCP 0.0.0.0:2869 Don-PC:0 LISTENING

Can not obtain ownership information

TCP 0.0.0.0:5357 Don-PC:0 LISTENING

Can not obtain ownership information

TCP 0.0.0.0:10243 Don-PC:0 LISTENING

Can not obtain ownership information

TCP 0.0.0.0:49152 Don-PC:0 LISTENING

[wininit.exe]

TCP 0.0.0.0:49153 Don-PC:0 LISTENING

eventlog

[svchost.exe]

TCP 0.0.0.0:49155 Don-PC:0 LISTENING

Schedule

[svchost.exe]

TCP 0.0.0.0:49156 Don-PC:0 LISTENING

[services.exe]

TCP 0.0.0.0:49158 Don-PC:0 LISTENING

PolicyAgent

[svchost.exe]

TCP 0.0.0.0:49160 Don-PC:0 LISTENING

[lsass.exe]

TCP 127.0.0.1:12025 Don-PC:0 LISTENING

[AvastSvc.exe]

TCP 127.0.0.1:12080 Don-PC:0 LISTENING

[AvastSvc.exe]

TCP 127.0.0.1:12110 Don-PC:0 LISTENING

[AvastSvc.exe]

TCP 127.0.0.1:12119 Don-PC:0 LISTENING

[AvastSvc.exe]

TCP 127.0.0.1:12143 Don-PC:0 LISTENING

[AvastSvc.exe]

TCP 127.0.0.1:12465 Don-PC:0 LISTENING

[AvastSvc.exe]

TCP 127.0.0.1:12563 Don-PC:0 LISTENING

[AvastSvc.exe]

TCP 127.0.0.1:12993 Don-PC:0 LISTENING

[AvastSvc.exe]

TCP 127.0.0.1:12995 Don-PC:0 LISTENING

[AvastSvc.exe]

TCP 192.168.1.1:139 Don-PC:0 LISTENING

Can not obtain ownership information

TCP 192.168.1.1:49179 download:http CLOSE_WAIT

[cmdagent.exe]

TCP 192.168.1.1:49180 vip1:http CLOSE_WAIT

[cmdagent.exe]

TCP [::]:135 Don-PC:0 LISTENING

RpcSs

[svchost.exe]

TCP [::]:445 Don-PC:0 LISTENING

Can not obtain ownership information

TCP [::]:554 Don-PC:0 LISTENING

[wmpnetwk.exe]

TCP [::]:2869 Don-PC:0 LISTENING

Can not obtain ownership information

TCP [::]:3587 Don-PC:0 LISTENING

p2pimsvc

[svchost.exe]

TCP [::]:5357 Don-PC:0 LISTENING

Can not obtain ownership information

TCP [::]:10243 Don-PC:0 LISTENING

Can not obtain ownership information

TCP [::]:49152 Don-PC:0 LISTENING

[wininit.exe]

TCP [::]:49153 Don-PC:0 LISTENING

eventlog

[svchost.exe]

TCP [::]:49155 Don-PC:0 LISTENING

Schedule

[svchost.exe]

TCP [::]:49156 Don-PC:0 LISTENING

[services.exe]

TCP [::]:49158 Don-PC:0 LISTENING

PolicyAgent

[svchost.exe]

TCP [::]:49160 Don-PC:0 LISTENING

[lsass.exe]

UDP 0.0.0.0:500 *:*

IKEEXT

[svchost.exe]

UDP 0.0.0.0:3702 *:*

EventSystem

[svchost.exe]

UDP 0.0.0.0:3702 *:*

FDResPub

[svchost.exe]

UDP 0.0.0.0:3702 *:*

EventSystem

[svchost.exe]

UDP 0.0.0.0:3702 *:*

FDResPub

[svchost.exe]

UDP 0.0.0.0:4500 *:*

IKEEXT

[svchost.exe]

UDP 0.0.0.0:5004 *:*

[wmpnetwk.exe]

UDP 0.0.0.0:5005 *:*

[wmpnetwk.exe]

UDP 0.0.0.0:5355 *:*

Dnscache

[svchost.exe]

UDP 0.0.0.0:50152 *:*

EventSystem

[svchost.exe]

UDP 0.0.0.0:53730 *:*

FDResPub

[svchost.exe]

UDP 0.0.0.0:59393 *:*

EventSystem

[svchost.exe]

UDP 127.0.0.1:1900 *:*

SSDPSRV

[svchost.exe]

UDP 127.0.0.1:54160 *:*

[iexplore.exe]

UDP 127.0.0.1:58787 *:*

[iexplore.exe]

UDP 127.0.0.1:59398 *:*

SSDPSRV

[svchost.exe]

UDP 192.168.1.1:137 *:*

Can not obtain ownership information

UDP 192.168.1.1:138 *:*

Can not obtain ownership information

UDP 192.168.1.1:1900 *:*

SSDPSRV

[svchost.exe]

UDP 192.168.1.1:59397 *:*

SSDPSRV

[svchost.exe]

UDP [::]:500 *:*

IKEEXT

[svchost.exe]

UDP [::]:3540 *:*

p2pimsvc

[svchost.exe]

UDP [::]:3702 *:*

FDResPub

[svchost.exe]

UDP [::]:3702 *:*

EventSystem

[svchost.exe]

UDP [::]:3702 *:*

EventSystem

[svchost.exe]

UDP [::]:3702 *:*

FDResPub

[svchost.exe]

UDP [::]:4500 *:*

IKEEXT

[svchost.exe]

UDP [::]:5004 *:*

[wmpnetwk.exe]

UDP [::]:5005 *:*

[wmpnetwk.exe]

UDP [::]:5355 *:*

Dnscache

[svchost.exe]

UDP [::]:50153 *:*

EventSystem

[svchost.exe]

UDP [::]:53731 *:*

FDResPub

[svchost.exe]

UDP [::]:59394 *:*

EventSystem

[svchost.exe]

UDP [::1]:1900 *:*

SSDPSRV

[svchost.exe]

UDP [::1]:59396 *:*

SSDPSRV

[svchost.exe]

UDP [fe80::bc6f:95da:5c92:456d%10]:546 *:*

924

Dhcp

[svchost.exe]

UDP [fe80::bc6f:95da:5c92:456d%10]:1900 *:*

1572

SSDPSRV

[svchost.exe]

UDP [fe80::bc6f:95da:5c92:456d%10]:59395 *:*

1572

SSDPSRV

[svchost.exe]

Link to post
Share on other sites

Since we are letting everything hang out, I am posting a screen short of malware related to mbamservice that Avast memory scanner found. Avast told me these are encrypted signatures or something on that order that their memory scanner cannot differentiate between the real bad guys. Just thought I would make you are of this.

post-84759-0-29644700-1308183576.jpg

Link to post
Share on other sites

Well, nothing in that netstat log is ours, unfortunately -- we're definitely not listening for connections from localhost. Have you installed or updated any other pieces of software recently? Failing that, it might be a good idea to post a log and check your system over for malware.

Is that a recent issue with Avast? i.e. if you use their updated definitions, do you get those detections? If so, I have to talk to them about whitelisting again. Thanks,

Link to post
Share on other sites

I didn't see anything strange in that netstat display either. System process listening on TCP port 10243 is used by Windows Media Player. Only active when streaming video.

Here is Avast's explaination of those memory scan results. They say the displays are not FPs.

They aren't FPs as you asked avast to scan the memory for malware, so don't be surprised when it finds (and reports) unencrypted virus/malware signatures in memory. It isn't mbamservice.exe that is infected, that is the process that loaded them into memory.

- Detections in Memory - My guess is that you are doing a Custom scan in which you have elected to scan Memory and that all these detections are in memory. Since they aren't physical files they can't be moved to the chest, deleted, etc. so there is no action that can be taken, hence the Apply button being greyed out.

The detections in memory are frequently other security applications loading unencrypted virus signatures into memory. Having set off a scan of memory by an antivirus application looking for virus signatures, don't be too surprised if it finds some in memory.

Link to post
Share on other sites

You keep mentioning posting logs? Do you mean the MBAM logs? They are all clean.

Only thing the Pro online log shows is it starting, ending, the scheduled activities (updating, scanning, etc.). I haven't had MBAM batch find anything on either my WIN7 or XP installations in ages. I have been running MBAM Pro for approx. 2 weeks and it has found nothing to date.

Link to post
Share on other sites

Hello DonZ :)

I'm just jumping in real quick for clarification. The logs that Mr. Swanson was referring to are those created by following the instructions posted here. If you do wish to verify that the system is indeed clean of infections, follow those instructions and post the resulting logs in a new topic here. Optionally, you may instead contact support@malwarebytes.org via email and one of our Support team members will assist you directly.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.