none
ton of outgoing TCP 3389 from svchost.exe

    Question

  • In a new windows 2003 R2 server, I'm noticing every few minutes, svshost.exe is opening a ton of outgoing TCP 3389 connections.  I ran an a/v scanner over it and it's clean.  Can it be hacked already???  has anyone seen this before?

     

    thank you


    BarrySDCA

    • Changed type Bruce-Liu Wednesday, September 07, 2011 7:59 AM
    • Changed type Bruce-Liu Tuesday, September 13, 2011 2:54 AM
    Thursday, August 25, 2011 6:13 PM

All replies

  • Seeing a similar issue at a client site. Any resolution? No AV scanners are detecting anything.
    Thursday, August 25, 2011 11:53 PM
  • I've run all the scanners over it I can think of.  nothing is detecting anything. yet running netstat -ano 1   and watching it shows every 10 min or so, a flood of TCP 3389 (which is RDP) connection attempts out to seemingly random IP addresses.  Our firewall is blocking it from getting out and it keeps trying. 

    I would normally delete and install a new one, however this was just reinstalled yesterday new because of the same issue.  I assumed it was a virus infection and something trying to brute force rdp hack out.  the subscriber HAS logged into the machine since we provisioned it, but i don't see anything unusual installed and nothing is detecting a virus or worm, etc..

     

     


    BarrySDCA
    Friday, August 26, 2011 12:14 AM
  • Have you tried applying MS11-065 yet?  http://www.microsoft.com/technet/security/bulletin/ms11-065.mspx

    This was released on 8/9 and addresses an RDP vulnerability.

    Friday, August 26, 2011 12:15 AM
  • It's already installed.  the OS is completely up to date.

     

    this is a hosted VM.  I have a feeling whatever it is, it came in over RDP disk share from the subscribers PC.


    BarrySDCA

    Friday, August 26, 2011 1:20 AM
  • In a new windows 2003 R2 server, I'm noticing every few minutes, svshost.exe is opening a ton of outgoing TCP 3389 connections.  I ran an a/v scanner over it and it's clean.  Can it be hacked already???  has anyone seen this before?

    First of all, hope that "svshost" is a typo and you meant "svchost" otherwise that process name would be really suspicious; that said, start by downloading this tool, extract the files from the "zip" to whatever suitable folder and then run the program; at this point locate the "svchost" instance carrying out all those RDP connections and double click on it; in the panel which will appear, look carefully at the path for the file and ensure it's pointing to the windows folder and not elsewhere, then click on the "services" tab and check which services are running under that instance; there may be some "strange" services there, if that's the case then you found your culprit

    As for scanning/cleaning the box, my suggestion is to find another clean/trusted machine (a regular PC) with a CD-burner and use it to download the Microsoft System Sweeper; done that, run the tool and proceed creating the CD; at that point, use the generated CD to boot the "problem system" and proceed with a full scan/clean

    Notice that, in case the scanner will find (and possibly remove) something, you must keep in mind that the system was (and is) compromised and that you can't trust it anymore; the best solution in such a case would be flattening and reinstalling the system; I know, it sounds "hard" but there's no other way to ensure that the system is really clean; if you aren't convinced, please read this and this

    HTH


    Friday, August 26, 2011 8:18 AM
  • Seeing a similar issue at a client site. Any resolution? No AV scanners are detecting anything.


    If it's a "rootkit" (as I suspect) a regular scanner won't probably be able to "see" it; to scan the system you'll need a scanner running from a boot CD like the Microsoft System Sweeper the problem is that many/most malware of this kind usually, after infecting a system, places a number of "hooks" in some calls (disk, registry) so a scanner running inside the compromised OS (and calling the OS function) will go through such hooks and, by the way, the malware will take care of hiding itself... or even crashing the scanner in some cases; this is why running the scan from a BootCD without activating the compromised OS is the only way to ensure to really scan the system

     

    Friday, August 26, 2011 10:06 AM
  • can you write complete information of packets ? from ip/port to ip/port
    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org
    Friday, August 26, 2011 12:36 PM
  • can you write complete information of packets ? from ip/port to ip/port

    Good point; a snippet of the output of a "netstat -ano" command would help clarify the issue !

     

    Friday, August 26, 2011 1:10 PM
  • I'm seeing similar issues with outbound 3389 on windows server 2003.  I have it blocked in my firewall but theirs over 10,000 outbound connections to random ip address on port 3389. Any word yet on what this is?

     

    Friday, August 26, 2011 3:06 PM
  • Can anyone confirm this file and/or fix?

    http://forums.majorgeeks.com/showthread.php?p=1659242

    Friday, August 26, 2011 3:09 PM
  • Can anyone confirm this file and/or fix?

    http://forums.majorgeeks.com/showthread.php?p=1659242

    First of all, the above thread is from 2007; second, instead of going through all that, I'd run the Microsoft System Sweeper (as for my other messages) booting the system from its CD and proceeding with a full scan; third, given that we're talking about a server... read this and this - also, and since we're at it; once the issue will be fixed, it will be a good idea ensuring that all your systems are up-to-date (servicepacks, hotfixes...) and, given that you can't know which data have been stolen from the system, you'll probably need to reset all passwords to avoid future intrusion attempts

     

    Friday, August 26, 2011 3:14 PM
  • please, post a snippet of the output of a "netstat -ano".
    Edoardo Benussi
    Microsoft MVP - Management Infrastructure
    edo[at]mvps[dot]org
    Friday, August 26, 2011 3:22 PM
  • please, post a snippet of the output of a "netstat -ano".

    Yeah; asked the same; that one may help a lot... also, once having such an output, it will be easier to use "process explorer" (see my other message in this discussion) to find out, using the process ID, the process carrying out those connections and, if it's an instance of svchost, to look at the services running under it

     


    Friday, August 26, 2011 3:29 PM
  • I keep trying to post the output but nothing happens. I guess this system doesn't let me post that many lines.
    Friday, August 26, 2011 5:12 PM
  • Here is the netstat output.  I replaced the actual IP for 1.2.3.4

    Also, I already checked it with processexplorer.  svchost.exe, nothing running under it

     

    Active Connections

      Proto  Local Address          Foreign Address        State           PID
      TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       4
      TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       708
      TCP    0.0.0.0:443            0.0.0.0:0              LISTENING       2256
      TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
      TCP    0.0.0.0:1027           0.0.0.0:0              LISTENING       464
      TCP    0.0.0.0:2717           0.0.0.0:0              LISTENING       2256
      TCP    1.2.3.4:139       0.0.0.0:0              LISTENING       4
      TCP    1.2.3.4:2258      144.176.55.204:3389    SYN_SENT        832
      TCP    1.2.3.4:2259      106.218.17.126:3389    SYN_SENT        832
      TCP    1.2.3.4:2260      82.159.196.249:3389    SYN_SENT        832
      TCP    1.2.3.4:2261      35.13.212.21:3389      SYN_SENT        832
      TCP    1.2.3.4:2262      98.89.156.119:3389     SYN_SENT        832
      TCP    1.2.3.4:2263      172.183.83.244:3389    SYN_SENT        832
      TCP    1.2.3.4:2264      2.22.184.226:3389      SYN_SENT        832
      TCP    1.2.3.4:2265      179.151.241.111:3389   SYN_SENT        832
      TCP    1.2.3.4:2266      188.131.141.230:3389   SYN_SENT        832
      TCP    1.2.3.4:2267      88.184.60.211:3389     SYN_SENT        832
      TCP    1.2.3.4:2268      19.246.27.204:3389     SYN_SENT        832
      TCP    1.2.3.4:2269      81.1.120.167:3389      SYN_SENT        832
      TCP    1.2.3.4:2270      104.115.210.138:3389   SYN_SENT        832
      TCP    1.2.3.4:2271      131.91.148.141:3389    SYN_SENT        832
      TCP    1.2.3.4:2272      106.33.203.220:3389    SYN_SENT        832
      TCP    1.2.3.4:2273      146.144.143.13:3389    SYN_SENT        832
      TCP    1.2.3.4:2274      112.102.238.103:3389   SYN_SENT        832
      TCP    1.2.3.4:2275      131.189.149.95:3389    SYN_SENT        832
      TCP    1.2.3.4:2276      102.153.148.25:3389    SYN_SENT        832
      TCP    1.2.3.4:2278      62.223.59.50:3389      SYN_SENT        832
      TCP    1.2.3.4:2279      23.176.169.236:3389    SYN_SENT        832
      TCP    1.2.3.4:2280      196.58.220.170:3389    SYN_SENT        832
      TCP    1.2.3.4:2281      210.22.139.241:3389    SYN_SENT        832
      TCP    1.2.3.4:2282      82.67.109.50:3389      SYN_SENT        832
      TCP    1.2.3.4:2283      82.67.109.50:3389      SYN_SENT        832
      TCP    1.2.3.4:2285      2.47.235.208:3389      SYN_SENT        832
      TCP    1.2.3.4:2286      83.119.15.163:3389     SYN_SENT        832
      TCP    1.2.3.4:2287      5.148.138.247:3389     SYN_SENT        832
      TCP    1.2.3.4:2288      5.148.138.247:3389     SYN_SENT        832
      TCP    1.2.3.4:2289      13.47.206.128:3389     SYN_SENT        832
      TCP    1.2.3.4:2290      13.47.206.128:3389     SYN_SENT        832
      TCP    1.2.3.4:2291      61.3.157.194:3389      SYN_SENT        832
      TCP    1.2.3.4:2292      2.254.66.234:3389      SYN_SENT        832
      TCP    1.2.3.4:2293      2.254.66.234:3389      SYN_SENT        832
      TCP    1.2.3.4:2294      80.205.112.59:3389     SYN_SENT        832
      TCP    1.2.3.4:2295      179.81.26.142:3389     SYN_SENT        832
      TCP    1.2.3.4:2296      37.99.211.28:3389      SYN_SENT        832
      TCP    1.2.3.4:2297      21.232.91.221:3389     SYN_SENT        832
      TCP    1.2.3.4:2298      120.206.193.11:3389    SYN_SENT        832
      TCP    1.2.3.4:2299      35.205.93.20:3389      SYN_SENT        832
      TCP    1.2.3.4:4258      92.123.154.57:80       CLOSE_WAIT      3428
      TCP    127.0.0.1:1547         0.0.0.0:0              LISTENING       2424
      TCP    127.0.0.1:5152         0.0.0.0:0              LISTENING       1704
      TCP    127.0.0.1:5152         127.0.0.1:3236         CLOSE_WAIT      1704
      UDP    0.0.0.0:445            *:*                                    4
      UDP    0.0.0.0:500            *:*                                    464
      UDP    0.0.0.0:4500           *:*                                    464
      UDP    1.2.3.4:123       *:*                                    1836
      UDP    1.2.3.4:137       *:*                                    4
      UDP    1.2.3.4:138       *:*                                    4
      UDP    127.0.0.1:123          *:*                                    1836
    ^C
    C:\

     

    they are not actually connecting because our firewall is detecting the RDP flood and killing the IP


    BarrySDCA
    Friday, August 26, 2011 5:26 PM
  • I have the same issue at one of my customers as well.  Been on the phone with Microsoft Networking team for 3 days.

    Do you have entries on your local workstations in the security logs for other computers trying to remote into them with random user accounts, and then failing?  this seems to be another symptom with this issue.

    Friday, August 26, 2011 5:29 PM
  • by the way, I used processexplorer and made a dump of svchost.exe if anyone wants to dissect it...


    BarrySDCA
    Friday, August 26, 2011 5:31 PM
  • Hello can anyone help us? We have exactly the same issue. For three days now. We have thrown 8 different scanners and malware fixes, but NOTHING.

    Windows servers 2003 and XP clients are infected and SYN FLOOD 3389 packets, which DDOS our firewall.

     

    The Guys from Panda say it is an MBR virus. They have analysed output from a thourough scan of one of our infected servers.

     

    In the process explorer we see: xpsp2res.dll spawning lots of UDP packets (about every 10 minutes, we use process explorer for this)

    We see a lot of DNS txt queries to jifr.net and trying to connect randomly to DNS servers.

    Wireshark displays  many times per second the following line:

    10 0.009460 192.168.1.9 111.105.166.32 TCP 66 4935 > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=1 SACK_PERM=1

    XP users sometimes get screenlocked by some ghost user who interactively logs on.

    We reveive strange emails about Xerox printers.

     

    We are struggling big time here, any help would be appreciated!

    Best regards

    Friday, August 26, 2011 5:36 PM
  • I had to stop the server so I can put more tools on it without risk of spreading infection.  booted the server again and about 10 minutes later it started.  I was able to catch on the netstat output 3 connections to an IP in China, port 80.  There is no reason for this server to be contacting IP's in China.  The IP is 122.228.207.69

     

    This must be the head-end of the thing

     

     

     

     


    BarrySDCA
    Friday, August 26, 2011 5:44 PM
  • Just a quick update from my end:

    i noticed in process monitor some read/write activity on the directory "c:\windows\offline web pages"

    when viewing in explorer, the files must be hidden, but when viewed in DOS, there are quite a few files there which appear to be malicious.

    I wasnt able to delete all the files from safe mode either.  I am going to work on tracking the exact process thread, and end it, then i should be able to delete all the files.

    let me know if you see the same in that directory as well.

    thanks.

    Friday, August 26, 2011 6:02 PM
  • Just a quick update from my end:

    i noticed in process monitor some read/write activity on the directory "c:\windows\offline web pages"

    when viewing in explorer, the files must be hidden, but when viewed in DOS, there are quite a few files there which appear to be malicious.

    I wasnt able to delete all the files from safe mode either.  I am going to work on tracking the exact process thread, and end it, then i should be able to delete all the files.

    let me know if you see the same in that directory as well.

    thanks.

    Ignoring the obnoxious comment from ObiWan and reiterating that this thread is relevant and current (and not from 2007 as he suggested)...pleas review....http://forums.majorgeeks.com/showthread.php?p=1659242.

    This seems to specifically state the problem at hand. Has anyone has success in removing these files?

    Friday, August 26, 2011 6:06 PM
  • I mounted the infected OS as drive D:

     

     Directory of D:\Windows\Offline web pages

    08/26/2011  10:38 AM    <DIR>          .
    08/26/2011  10:38 AM    <DIR>          ..
    08/25/2011  06:30 AM                 0 1.60_0824
    08/24/2011  04:13 PM                 0 2011-08-24 2313
    02/18/2007  05:00 AM             7,184 cache.txt
    08/26/2011  11:10 AM                29 MainThread.txt
    08/26/2011  01:36 PM                27 MainThreadStart.txt
    08/26/2011  11:10 AM                29 SHUTDOWN.txt
    08/26/2011  11:10 AM                29 SHUTDOWN2.txt
    08/26/2011  11:09 AM                29 ThreadProtect.txt
                   8 File(s)          7,327 bytes
                   2 Dir(s)   6,673,936,384 bytes free

    C:\

     

    these files can not be viewed by windows explorer

     

    I'm not so much concerned with cleaning this server.  I can reprovision it in a few minutes.  I already did that once and the subscriber infected it again over night.  I'm more concerned with identifying the infection and finding a tool to clean it, so I can send it to the subscriber to run on their PC.

     

    I'm not sure it's the same thing.  the other thread is not saying anything about outgoing TCP 3389

     

    thank you


    BarrySDCA
    Friday, August 26, 2011 6:17 PM
  • I was able to remove it by using process explorer to determine the PID of the process, then used process explorer to kill the process, and  then used command prompt to delete everything in the Offline Web Pages directory.  Looks clean for now.

    Also note that this infection appears to spread through the network.  I'd recommend checking all computers for it.

    Hope this helps.

    • Proposed as answer by Ian Silber Friday, August 26, 2011 7:17 PM
    • Unproposed as answer by BarrySDCA Friday, August 26, 2011 10:10 PM
    Friday, August 26, 2011 6:42 PM
  • I tried running system sweeper.  It can't run.  says "Microsoft Standalone System Sweeper cannot be started.  Please contact support.  Error code 0x8004cc05

     

    I read on the net that I can get past the error by disabling the floppy drive in the BIOS.  Only this is a hyper-v VM, and I don't think I can do that.  No options to in HV VM settings.  I also tried inserting a blank floppy, no luck.


    BarrySDCA
    Friday, August 26, 2011 7:05 PM
  • I just tried Sophps Anti-rootkit.  Near the end, the OS reboots.  I'm not sure if this is normal or premature.  No mention of any hits when it comes back up.
    BarrySDCA
    Friday, August 26, 2011 8:42 PM
  • Barry,

    Please follow my instructions above.  They work.

    Friday, August 26, 2011 8:42 PM
  • also regarding the PID responsible for making the connection attempt to China....

     

    I have blocked that.  so now I noticed in netstat, UDP open port 1028-1031 same PID

     

    and the path for svchost.exe is C:\WINDOWS\system32

     


    BarrySDCA

    Friday, August 26, 2011 8:55 PM
  • norton power eraser doesn't work either. after reboot, BSOD in a loop when checking rootkit.

    other norton power eraser scan returns no hits.  suspicoius windump.exe file but further details show it's a popular file. odd 

    I already have a backup of this infected VM for further testing.

     


    BarrySDCA

    Friday, August 26, 2011 9:51 PM
  • I'm not so much concerned with cleaning this server. I can reprovision it in a few minutes. I already did that once and the subscriber infected it again over night. I'm more concerned with identifying the infection and finding a tool to clean it, so I can send it to the subscriber to run on their PC.  thank you
    BarrySDCA
    Friday, August 26, 2011 10:10 PM
  • received from microsoft:

     

    Hi Barry,

     

    Thanks a lot you're your report -- this issue is already on the radar of the MMPC (Microsoft Malware Protection Center) and they will take the necessary action to contain this issue.

     

    Kind regards,

    Joe


    BarrySDCA
    Saturday, August 27, 2011 2:14 AM
  • After speaking with MMPC last night, and sending them the malicious files, they came back to me with this:

    http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?name=Backdoor%3aWin32%2fMorto.A

    I havent tried their resolution / scanners yet, but give it a shot.  Just make sure you have the latest definition files.

    • Proposed as answer by Ian Silber Saturday, August 27, 2011 3:04 PM
    Saturday, August 27, 2011 3:03 PM
  • I had to stop the server so I can put more tools on it without risk of spreading infection.  booted the server again and about 10 minutes later it started.  I was able to catch on the netstat output 3 connections to an IP in China, port 80.  There is no reason for this server to be contacting IP's in China.  The IP is 122.228.207.69

     

    This must be the head-end of the thing

     

     

     

     


    BarrySDCA


    One of my customers has a Terminal Server that a couple of their remote users RDP into using the default port of 3389.  They all have relatively simple passwords and because RDP was allowed from any IP, I'm betting something scanned for public IPs with TCP 3389 open and did dictionary attacks (I did see a slew of failed login attempts in my Security log).  While they may have been opposed to it before, they have agreed to close the port and force remote connections to use their SBS Remote Web Workplace (specifically, the terminal services proxy).

    The symptoms we saw were that the Internet connection came to a crawl, and after running a packet capture on the firewall, I identified that their Terminal Server was trying to open RDP connections to seemingly random IP addresses and I also noticed several established connections to 103.22.244.75 and 122.228.207.69 on port 80 (all from the same svchost PID as the attempted RDP connections).  When I added those to my outbound deny ACL and closed the connections, the process began trying to reconnect the HTTP connections similar to how it kept attempting the RDP connections.  Then after a minute or two, it got much worse as it started opening HTTP connections to random IP addresses to the point where i just blocked all outbound network access from the Terminal Server.

    I am usually pretty good at removing malware, but this one has me stumped.


    Sr System Engineer
    Saturday, August 27, 2011 5:21 PM
  • Also, I noticed that the svchost with the same PID that causes all of this bizarre traffic is listening on TCP 4764, although that is not open on my firewall...not sure if this is related.
    Sr System Engineer
    Saturday, August 27, 2011 5:22 PM
  • And the plot thickens.  Although the customer agreed to block 3389 at the firewall and use the terminl services gateway moving forward, that has not been done yet.  After blockng all outbound access, I noticed a new user account, 'sys', was created and an inbound RDP connection was established from 178.162.174.77, logging in as this new user!

    I reset the password and took control of the session via Terminal Services Manager and there was a folder open (C:\temp\Xenu1\Xenu1\Xenu), and xenu.exe was running from this folder (which was created in the last 10 minutes).  It seems that everything I do to try and remove this infection makes the problem worse. 

    Although it is generally recommended not to run ComboFix on servers, I'm running out of options, so here goes...


    Sr System Engineer
    Saturday, August 27, 2011 5:30 PM
  • Duh, forgot Combofix won't run on Server 2003.  Instead I ran Sysinternals' RootkitRevealer a few times, removed some scheduled tasks (there were two that were running executables from c:\program files\real\..., but RealPlayer was not installed.  These may or may not be related.), and rebooted.  I still see attempted HTTP connections to China, but no RDP attempts.  This might just be due to the fact that the HTTP connection cannot be established...
    Sr System Engineer
    Saturday, August 27, 2011 6:06 PM
  • Derek,

    If you are infected with Backdoor:Win32/Morto.A, I posted manual removal instructions above.  Give that a try.

    I am in the middle of testing an automated removal from Microsoft.  I will post up as soon as it completes to see if it works or not.

    My instructions do not advise on xenu.exe issue.  that is likely a seperate piece of malware.

    Saturday, August 27, 2011 6:12 PM
  • This virus is un beatable. I realy hope anyone has cleaned an infected pc/server once. I haven't and have been working non stop for four days!

    This is what I found so far:

    - the virus fetched pictures (jpg, png, gif) from a chinese website (looks like some kind of gaming web site): WWW.345ZX.COM

    - it does DNS queries against random DNS servers for: db1/db2/sb/fb1/fb2/fb3.jifr.net and also jaifr.com

    - It hides in SVCHOST.EXE (the one with the critical windows stuff in it)

    - When you shut down windows, you will get a SVCHOST.EXE proper shutdown error

    - Only XP and 2003 are infected

    - RDC, TCP, UDP SYN FLOODS to random public ip's

    - Sometimes it is dorment but I don't know why or when;

    - After a boot, the virus does a quick challenge response with 11.68.13.250 and after this the FLOOD starts. (not shure if it always uses this ip or in this fassion).

    DOES ANYONE RECOGNIZE THIS DESCRIPTION?

    Thanks,

    Sander!

    PS these gifs, jpg's are fetched by the virus:

     

    Saturday, August 27, 2011 6:27 PM
  • I also saw the DNS queries on my Server 2003 Terminal Server.  The RDC, TCP, UDP SYN floods to random public IPs (and HTTP connections to China mentioned before) all come from the same svchost PID, but that PID is responsible for about a dozen Windows services that cannot be shutdown.  I remotely rebooted the server into Safe Mode with Networking and now it's not responding, so I'm assuming the malware also broke Safe Mode.  I likely won't be back onsite to further troubleshoot the issue until Monday morning.

    I also found strange IE toolbars installed and some entries in Add/Remove Programs, but I removed these yesterday without documenting what they were.  There were also a few local administrator accounts (test, sys, services) created, and I removed these as well.  I had the latest version of Trend Micro Worry-Free Business Security installed and it is gone now, and the installer keeps crashing, so now I have no A/V on this server.

    I like a challenge as much as the next guy, but I'm sick of this malware...


    Sr System Engineer
    Saturday, August 27, 2011 6:34 PM
  • Update so far:

     

    There are files in c:\windows\offline webpages which are only visible through dos box (cmd).

     

    the fie 1.60_0823 could be the virus.

     

    The files: cache.txt, shutdown.txt and shutdown2.txt are both part of the virus. You can delete cache.txt but it reapears in seconds. Shutdown.txt and shutdown2.txt show up after reboot.

    I am now deleting the content of c:\windows\offline webpages from a boot cd. Let's see what happens.

    Sunday, August 28, 2011 9:11 AM
  • Darn... the virus was quiet for a long time after deleting the content of windows\offline webpages. Now it's back again...

     

    The search is not yet over.

    Sunday, August 28, 2011 10:18 AM
  • Name of the virus most likely MORTO.A

    Read this article from microsoft, posted august 28 2011.

    http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Worm%3aWin32%2fMorto.A

     

    Sunday, August 28, 2011 12:43 PM
  • I have a clone of the VM before Norton hosed it.  Today I will load that clone and test this removal tool, and then follow-up with results.  thanks much


    BarrySDCA
    Sunday, August 28, 2011 4:30 PM
  • And in my current knowledge, if you get infected, it means you have way too EASY PASSWORD.
    - Meitzi
    Sunday, August 28, 2011 4:51 PM
  • Not sure about that Meitzi because I just got hit by this and my server only has 2 admin accounts and the passwords are very strong.  I did fix it as far as I know by booting from a linux cd and deleting the contents of windows\offline web pages and it appears to be fixed.  The 3389 calls have stoped.

    I have a 2003 server in a co-location and my provider emailed me a warning that I exceeded my bandwidth utilization by 2500% yikes.  I looked at the logs and at one point this thing was uploading 8 GB an hour to my server for about 3 hours.  What the hell was it doing?  I'm still not comfortable that my machine is clean and I will probably move everything off and blow it up.  Does anyone know if sens32.dll is a legit file?  I have it on my server but the date is 02-17-2007 37 kb and signed by MS.

     

    Sunday, August 28, 2011 6:52 PM
  • I had to manually download the windows defender definitions from http://www.microsoft.com/security/portal/Definitions/ADL.aspx  because our windows update server has not yet downloaded them.

     

    After updating the definitions to 1.111.925.0 and running a full scan, defender did not detect any issues.  However, after examining the OS and waiting for it to call out again, it's not doing that either.  It *may* be because I have blackholed the domains and IP's mentioned in the MS article http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Worm%3aWin32%2fMorto.A

     

    A few items I should point out.  This VM was not calling out to the IP's mentioned by Microsoft.  It was connecting to an IP in China, which is 122.228.207.69

     

    Also, Microsoft listed two IP's in their information page about this.  they are: 210.3.38.820 & 74.125.71.104

    The first IP is an invalid IP, so I assumed they meant 210.3.38.20 and have blackholed that IP.

    This infected VM has some of the files Microsoft lists as a sign of infection, such as sens32.dll, so perhaps this is already a variant?

    I will continue to monitor and advise if it calls out again.  In the mean time, I am not certain this definition is a 100% resolution.

    @Meitzi:  that is correct, it very well could be due to an easy password.   I suspect the subscriber changed their Administrator password, but I have not confirmed that with them yet.


    BarrySDCA
    Sunday, August 28, 2011 8:13 PM
  • I don't recall seeing outbound connection attempts to the IP's Microsoft listed, but I too saw connection attempts to 122.228.207.69, so I agree that this is probably a variant.  I also saw a lot of connection attempts to 103.22.244.75 (actually, this is what I see the most, and although I thought it was a Chinese IP, it appears to be an Australian IP).  I'm going to do some more testing in the AM (Eastern time) with BartPE and some offline scanners, and I will post back with anything I find.
    Sr System Engineer
    Sunday, August 28, 2011 8:28 PM
  • I also notice the infected VM is listening to the following TCP ports as per netstat. 

    1027, 2717


    BarrySDCA
    Sunday, August 28, 2011 8:35 PM
  • One more item to mention:  the worm description says it only affects 2003 and XP.  I am certain the VM was infected by a RDP disk share.  The subscriber only logged into it once - and from a Win7 box.  they installed one software package that is fairly common and I have no reason to believe it is infected.

     

     


    BarrySDCA

    Sunday, August 28, 2011 9:30 PM
  • By any chance is any of your Local or Domain Administrator passwords low strength, common or easy to type etc? as listed in a link SanderWeb and Barry put up?

    http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Worm%3aWin32%2fMorto.A

    It may not affect 2008 systems in general because the passwords are strong by default.



    Sunday, August 28, 2011 11:50 PM
  • the default password we issue is relatively strong.  and I doubt the subscriber changed it to any on that list but I'm still waiting on confirmation.  they are in Malaysia and awake different hours.
    BarrySDCA
    Sunday, August 28, 2011 11:57 PM
  • The particular machine I was working on was infected on Wednesday morning, 8/24, over the default RDP port of 3389.  The server is 2003 Enterprise with all of the latest patches (as of that day), but yes, I can confirm it was a weak administrator password.  Although it was a weak password (6 character dictionary word comprised of only lower-case characters), it was not in the list of words in Barry's link.  The compromised password is the same on some of the older PCs in the same office, on the same subnet, but in the several hours I watched repeated outbound RDC attempts, I never once saw it try to reach another machine on the local subnet.  From what I could tell, this piece of malware installed a few browser toolbars (OoVoo is the only one that stands out in my mind) and performed a DoS attack by way of attempting dozens, if not hundreds, of RDC attempts every minute.  The connection attempts saturated the Internet connection, which is what led to the discovery of this particular problem.

    I saw an article on Slashdot about this problem earlier this evening which linked to an article on threatpost.com (here: https://threatpost.com/en_us/blogs/new-worm-morto-using-rdp-infect-windows-pcs-082811), so this is turning out to be more widespread than I originally thought.


    Sr System Engineer
    Sunday, August 28, 2011 11:59 PM
  • The subscriber has responded to me and said he did not change the Administrator password from the default we issued.    At the time it was infected, the Administrator password was 2o9yuWaS02

     

     


    BarrySDCA
    Monday, August 29, 2011 1:03 AM
  • Looks like we repaired it:

    The virus/wrm/botnet is running in some stages.

    In most active stage we cleaned the virus.
    Sens32.dll is the main engine in the virus when it is full active.

    This is the main steps we used.

    Install patch: http://support.microsoft.com/kb/2570222


    Stop and disable "system event Notifier" service. This is using sens32.dll instead of sens.dll


    Clean the registry:
    Delete the complete key and everyting under it (we didn't see it on servers only on xp machines)
    HKLM\SYSTEM\CurrentControlSet\Services\6to4

    Clean the keys under not the folders! (Look if Ias and/or 6to4 is standing in one of the keys)
    HKLM\SYSTEM\WPA\

    Change the next key back to normal:
    subkey: HKLM\SYSTEM\CurrentControlSet\Services\Sens\Parameters
    value: "ServiceDll"
    data: "<system folder>\sens.dll"

    Restart machine:

    Delete everyting under (del *.*):
    c:\windows\offline web pages\

    delete c:\windows\system32\sens32.dll
    if you cant delete sens32.dll repeat the steps before restart.

    enable and start "system event Notifier" again.

    Sometimes ther is a extra services Ias this uses chache.txt or Sens32.dll or a other morfed file.
    What i Notices about this that this looks like 1 of the fases the virus goes true when it is starting up.

    now we need to wait and see if this realy fixt the worm.
    we also see some (older) files that points out that this is a botnet used for ddos atacks (files like 1.40 testddos)!!!!
    if we look at thhe files it has been activated for use in the botnet 27 aug 2011 but started on the 4th.

    IMPORTAND:
    microsoft enpoint protection can detected some of it but not all. All virus scanners can't clean it!
    (at the moment of writing this artical)

    this is typed after working a realy long day ;-)

    (edit some typo's and added extra info)
    • Proposed as answer by Brown, Derek Monday, August 29, 2011 12:40 PM
    • Edited by A D van Dijk Monday, August 29, 2011 1:45 PM more info and explanation
    Monday, August 29, 2011 3:07 AM
  • I'm a bit concerned becuase our subscriber logged into the OS by RDP from a Win7 machine, and I'm certain it was infected by RDP disk share.  There is no brute force RDP hacking in the event logs and our IPS/firewalls would kill that quick anyway, in or out.  It's how it was identified so quickly.

    All the pages I'm reading on this thing say WinXP/2003 only.  Sure this is a 2003 R2 OS, but the client infected it from his Win7 machine.  It has got to be the case

     

     


    BarrySDCA
    Monday, August 29, 2011 4:51 AM
  • Seems like there is significant awareness of this thanks to everyone's efforts here on this thread. I read coverage on F-Secure (Finland) weblog Windows Remote Desktop worm "Morto" spreading:

    "We detect Morto components as Backdoor:W32/Morto.A and Worm:W32/Morto.B"

    The author, Mikko Hypponen (I hope I spelled his name correctly), provides the link returning here to Technet for full details. I even found a heads-up mention, as a possible Windows Remote Desktop Worm, on Reddit about 18 hours ago.

    Y'all worked really hard over the weekend on this. And helped lots of users. Like me. Thank you.


    ~~~~~~~ lux et veritas ~~~~~~
    • Edited by EllieK Monday, August 29, 2011 10:03 AM typo
    Monday, August 29, 2011 10:02 AM
  • Some more analyzing the virus: <extended the list from microsft>

    HTTP Connection:
    122.228.207.69
    122.228.207.68

    DNS Servers used:
    210.3.38.20 (removed typo) 
    74.125.71.104
    4.2.2.2
    8.8.8.8
    <25 more Public DNS>

    DNS queries done
    ALL TXT
    jaifr.com
    jifr.info

    jifr.co.cc
    jifr.co.be
    qfsl.net
    qfsl.co.cc
    qfsl.co.be
    jifr.net

    TCP 3389 Syn packets:
    TCP    1.2.3.4:2258      144.176.55.204:3389    SYN_SENT        832
      TCP    1.2.3.4:2259      106.218.17.126:3389    SYN_SENT        832
      TCP    1.2.3.4:2260      82.159.196.249:3389    SYN_SENT        832
      TCP    1.2.3.4:2261      35.13.212.21:3389      SYN_SENT        832
      TCP    1.2.3.4:2262      98.89.156.119:3389     SYN_SENT        832
      TCP    1.2.3.4:2263      172.183.83.244:3389    SYN_SENT        832
      TCP    1.2.3.4:2264      2.22.184.226:3389      SYN_SENT        832
      TCP    1.2.3.4:2265      179.151.241.111:3389   SYN_SENT        832
      TCP    1.2.3.4:2266      188.131.141.230:3389   SYN_SENT        832
      TCP    1.2.3.4:2267      88.184.60.211:3389     SYN_SENT        832
      TCP    1.2.3.4:2268      19.246.27.204:3389     SYN_SENT        832
      TCP    1.2.3.4:2269      81.1.120.167:3389      SYN_SENT        832
      TCP    1.2.3.4:2270      104.115.210.138:3389   SYN_SENT        832
      TCP    1.2.3.4:2271      131.91.148.141:3389    SYN_SENT        832
      TCP    1.2.3.4:2272      106.33.203.220:3389    SYN_SENT        832
      TCP    1.2.3.4:2273      146.144.143.13:3389    SYN_SENT        832
      TCP    1.2.3.4:2274      112.102.238.103:3389   SYN_SENT        832
      TCP    1.2.3.4:2275      131.189.149.95:3389    SYN_SENT        832
      TCP    1.2.3.4:2276      102.153.148.25:3389    SYN_SENT        832
      TCP    1.2.3.4:2278      62.223.59.50:3389      SYN_SENT        832
      TCP    1.2.3.4:2279      23.176.169.236:3389    SYN_SENT        832
      TCP    1.2.3.4:2280      196.58.220.170:3389    SYN_SENT        832
      TCP    1.2.3.4:2281      210.22.139.241:3389    SYN_SENT        832
      TCP    1.2.3.4:2282      82.67.109.50:3389      SYN_SENT        832
      TCP    1.2.3.4:2283      82.67.109.50:3389      SYN_SENT        832
      TCP    1.2.3.4:2285      2.47.235.208:3389      SYN_SENT        832
      TCP    1.2.3.4:2286      83.119.15.163:3389     SYN_SENT        832
      TCP    1.2.3.4:2287      5.148.138.247:3389     SYN_SENT        832
      TCP    1.2.3.4:2288      5.148.138.247:3389     SYN_SENT        832
      TCP    1.2.3.4:2289      13.47.206.128:3389     SYN_SENT        832
      TCP    1.2.3.4:2290      13.47.206.128:3389     SYN_SENT        832
      TCP    1.2.3.4:2291      61.3.157.194:3389      SYN_SENT        832
      TCP    1.2.3.4:2292      2.254.66.234:3389      SYN_SENT        832
      TCP    1.2.3.4:2293      2.254.66.234:3389      SYN_SENT        832
      TCP    1.2.3.4:2294      80.205.112.59:3389     SYN_SENT        832
      TCP    1.2.3.4:2295      179.81.26.142:3389     SYN_SENT        832
      TCP    1.2.3.4:2296      37.99.211.28:3389      SYN_SENT        832
      TCP    1.2.3.4:2297      21.232.91.221:3389     SYN_SENT        832
      TCP    1.2.3.4:2298      120.206.193.11:3389    SYN_SENT        832
      TCP    1.2.3.4:2299      35.205.93.20:3389      SYN_SENT        832

    Sens32.dll is showing up in proccess explorer.
    If you stop 'system event notification' its still not possible to delete sens32.dll

    Sometimes a services 'Ias' is also active this runs to the same DLL. This can be cleaned in the registry

    Under 'HKLM\SYSTEM\WPA\' its possible to see the services in use need some more exploring for it to get a final clue how that is working.


    Monday, August 29, 2011 11:14 AM
  • You can try downloading the Microsot Safety Scanner, it should detect/remove this. 

    http://www.microsoft.com/security/scanner/en-us/default.aspx

    Also, if you were infected by this malware then it's likely you are using one of the passwords listed in our writeup: http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Worm%3AWin32%2FMorto.A

    If that is the case, then please change to a stronger password.

    Thanks,

    Faron [MSFT]


    Faron Faulk [MSFT]
    Monday, August 29, 2011 12:35 PM
  • Microsot Safety Scanner detects the virus but it doesn't clean the System completly so it come's back after a wile if you don't clean manualy the reg keys.

    MSep doesn't clean the reg keys:
    HKLM\SYSTEM\CurrentControlSet\Services\6to4
    HKLM\SYSTEM\WPA\

    This was still so at 29 aug 2011 around 4 AM GMT +1

    Monday, August 29, 2011 12:53 PM
  • Looks like we fixt it:

    The virus/wrm/botnet is running in some stages.

    In most active stage we cleaned the virus.
    Sens32.dll is the engine in the virus we think.

    Stop thet service and disable "system event Notifier" (its using sens32.dll instead of the standerd sens.dll)

    Clean the registry:
    Delete the complete key and everyting under it (we didn't see it on servers only on xp machines:
    HKLM\SYSTEM\CurrentControlSet\Services\6to4

    Clean teh keys under not the folders!
    HKLM\SYSTEM\WPA\

    Change key back to normal:
    subkey: HKLM\SYSTEM\CurrentControlSet\Services\Sens\Parameters
    Adds value: "ServiceDll"
    With data: "<system folder>\sens.dll"

    Restart machine:
    Delete everyting underneed:
    c:\windows\offline web pages\

    delete c:\windows\system32\sens32.dll
    if you cant delete sens32.dll repeat the steps.

    enable and start "system event Notifier" again.

    now we need to see if this realy fixt the worm.
    we also see some (older) files that points out that this is a botnet used for ddos atacks!!!!
    if we look at thhe files it has been activated for use in the botnet 27 aug 2011 but started on the 4th.

    microsoft enpoint protection can detected some of it but not all. all virus scanners can't clean it!!!!

    this is typed after working a realy long day ;-)


    I rebooted into Safe Mode, emptied the folder C:\WINDOWS\Offline Web Pages, rebooted, and the symptoms are gone.  I'm reinstalling my A/V (Trend Micro Worry-Free Business Security 7, which was previously installed - this malware apparently removed it) and I'm going to run a scan with that as well as the Microsoft Safety Scanner once it finishes.  I was not able to locate sesn32.dll, did not have a "6to4" key, and the key/values for the SENS service all appear to be legit, even pointing to the correct sens32.dll.  I did have to cleanup the WPA key, remove the "NoPopUpsOnBoot" value, and add the dependency on EventSystem for the SENS service.

     

    I know it has already been mentioned before, but Microsoft's information is incomplete, as the compromised password on my system was b**** (not a dirty word, just masked for my client's privacy), and this is not on the password list.  Also, if you have any of these symptoms, check for any HTTP connections to 122.228.207.69, as this IP was not in Microsoft's list, but was common to myself and BarrySDA (and after removing the suspect files, there are no more connections to this IP), so I'm pretty sure it is related.


    Sr System Engineer
    Monday, August 29, 2011 12:55 PM
  • sens32.dll is the virus!!

    needs to be sens.dll

    Http to 122.228.207.68 is also used

    the symptoms come back after a wile when only 'C:\WINDOWS\Offline Web Pages' is cleaned. (del *.*).
    after a while chache.txt comes back and teh proccess and the symtoms come back.

    Monday, August 29, 2011 1:01 PM
  • sens32.dll is the virus!!

    needs to be sens.dll

    Http to 122.228.207.68 is also used

    the symptoms come back after a wile when only 'C:\WINDOWS\Offline Web Pages' is cleaned. (del *.*).
    after a while chache.txt comes back and teh proccess and the symtoms come back.


    Thanks for pointing that out!  I was able to move sens32.dll to the desktop and update the registry value back to sens.dll, but I cannot delete sesn32.dll (even though I could move it), as it is in use by svchost!  I also double-checked everything and saw that there was still a service called Ias with no description (trying to launch the deleted cach.txt), so I removed that as well.
    Sr System Engineer
    Monday, August 29, 2011 1:17 PM
  • FYI -- Encountered many of these same symptoms on a 2008 R2 system starting on Friday Aug 26th.  Cleaned with MS Safety Scanner and blocked outgoing WAN traffic.  Have not seen any re-occurrence as of yet.
    Monday, August 29, 2011 1:22 PM
  • Can anyone shed some light into how logging works for RDP on Windows 7? On my home computer, I have enabled RDP, but only allowing connections from computers running with Network Level Authentication. In Event Viewer I can find entries under "Applications and Service logs - Microsoft - Windows - TerminalServices RemoteConnectionManager - Operational. But the entries are only "Listener RDP-Tcp received a connection". I would like to know: From where did the connection come from, which username were supplied, etc Anyone?
    Monday, August 29, 2011 1:32 PM
  • AD, are you changing the password that is used for RDP user(s)?  if it's coming back 'after a while' that sounds like the attacker is just guessing your password again, possibly.

    Faron


    Faron Faulk [MSFT]
    Monday, August 29, 2011 1:41 PM
  • no its not the password. The virus it self is still running under "system event notifier" (sens32.dll).
    This even happend without any network connection.

    Monday, August 29, 2011 1:55 PM
  • People keep saying "weak password" or "XP/2003".  I know both of these are not the case.

    The 2003 OS had a reasonably strong password, which I posted above and was infected by RDP disk share from a Win7 machine.


    BarrySDCA
    Monday, August 29, 2011 2:40 PM
  • way's off possible infection:
    - weak password
    - TS Client can be infected by a Infected TS server
    - TS Server can be infected by a Infected TS Client
    - Some kind of keylogging.
    - Phishing email (most likly we got the first infection in first place)
    - Infected webserver
    - Weaknis that is fixt in patch (makes spreadung virus going faster)

    ao there are alot off ways to get this virus.
    Havent seen it on Windows 7 or server 2008 yet.

    Monday, August 29, 2011 3:22 PM
  • People keep saying "weak password" or "XP/2003".  I know both of these are not the case.

    The 2003 OS had a reasonably strong password, which I posted above and was infected by RDP disk share from a Win7 machine.


    BarrySDCA


    Barry,

    I do not believe Win7 or Server 2008 can get this malware.  At least I havent seen it.  I saw it on a network with 2 server 2003 boxes, 10+ XP, 10+ Win7, and the only boxes infected were the 2003, and 90% of the XP ones...

    I also believe it started due to a service account with a weak password, and too much privs...

    Monday, August 29, 2011 3:42 PM
  • Update:

     

    Windows defender with definitions 1.111.925.0 did NOT detect this worm in the infected 2003 R2 OS

    Microsoft Safety Scanner 1.0.3001.0 DID detect the worm in the infected 2003 R2 OS

     

    In regards to how the OS was infected, here are the facts:

    We noticed a bunch of outgoing RDP hits on our firewall.  It was determined to be infected and reprovisioned as NEW, fully patched 2003 R2.

    The subscriber logged into the VM by RDP from a Win7 box, with shared disks, and the VM was infected in under 24 hours.  They have told me the only box they used to login to the VM was their Win7 PC.  They installed one software package, which I do not believe is reasonable to assume was the source of the infection.

    The Administrator password of the VM at the time of infection was 2o9yuWaS02

    NO RDP brute force hacking detected in event logs.  Yes, event logs were configured to show this information when the VM was provisioned.


    BarrySDCA
    Monday, August 29, 2011 3:55 PM
  • People keep saying "weak password" or "XP/2003".  I know both of these are not the case.

    The 2003 OS had a reasonably strong password, which I posted above and was infected by RDP disk share from a Win7 machine.


    BarrySDCA


    Barry,

    I do not believe Win7 or Server 2008 can get this malware.  At least I havent seen it.  I saw it on a network with 2 server 2003 boxes, 10+ XP, 10+ Win7, and the only boxes infected were the 2003, and 90% of the XP ones...

    I also believe it started due to a service account with a weak password, and too much privs...

    Ian,

     

    I have seen firsthand (as mentioned above) that this worm CAN and DOES infect hosts running Server 2008 R2.  During my investigation, I also found no evidence of brute force, but certainly infected svchost and the ntshrui.dll was attempting load at startup.  Also found multiple outbound HTTP connections to chinese IP addresses.  MS Safety Scanner did detect and (seemingly) cleaned.

    Monday, August 29, 2011 4:20 PM
  • BEWARE! I had ntshrui.dll running as "FastUserSwitchingCompatibility" service. sr value under HKLM\SYSTEM\Wpa points to the service it runs as so I suspect that it can dynamically alter the service its runs as, so don't take the writeup as an absolute because the service execution is definitely not static!

    netstat -nb  will tell you which service its running as under svchost.exe

    Also, I don't know this for certain but once this thing has infected a machine through a brute force attack it may be able to penetrate other machines by way of trusted credentials between the infected machine and the target.

    -Ted-

    Monday, August 29, 2011 5:09 PM
  • BEWARE! I had ntshrui.dll running as "FastUserSwitchingCompatibility" service. sr value under HKLM\SYSTEM\Wpa points to the service it runs as so I suspect that it can dynamically alter the service its runs as, so don't take the writeup as an absolute because the service execution is definitely not static!

    netstat -nb  will tell you which service its running as under svchost.exe

    Also, I don't know this for certain but once this thing has infected a machine through a brute force attack it may be able to penetrate other machines by way of trusted credentials between the infected machine and the target.

    -Ted-

    It runs as svchost, but under different/random PID's with services attached.  in fact, i saw it move to another process after i stopped the current process it was running as!
    Monday, August 29, 2011 5:32 PM
  • After running this fix, have you seen the issue return? Also, did you script any of this?
    Monday, August 29, 2011 5:43 PM
  • Try to suspend the process if possible using process explorer, if they have a "buddy" process that watch each other they will notice the terminated one and start another.
    Monday, August 29, 2011 5:47 PM
  • It runs as svchost, but under different/random PID's with services attached.  in fact, i saw it move to another process after i stopped the current process it was running as!

    svchost is basically a container for services. You'll notice many svchost processes running in order to host various services, inculding the service that Morto is running as. If you look closely at an netstat -nb you will not only see the svchost.exe process but YOU WILL ALSO SEE THE SERVICE NAME that Morto is running as on the line above. netstat -nb CAN be used to find the SERVICE Morto is running as. The service NAME in not different/random in my experience, although the name I've seen differs from the names(s) I have thus far seen published elsewhere. Almost ALL PIDs are assigned dynamically every time a machine restarts or a process goes through its full life cycle, no surprise here.
    Monday, August 29, 2011 6:02 PM
  • It runs as svchost, but under different/random PID's with services attached.  in fact, i saw it move to another process after i stopped the current process it was running as!

    svchost is basically a container for services. You'll notice many svchost processes running in order to host various services, inculding the service that Morto is running as. If you look closely at an netstat -nb you will not only see the svchost.exe process but YOU WILL ALSO SEE THE SERVICE NAME that Morto is running as on the line above. netstat -nb CAN be used to find the SERVICE Morto is running as. The service NAME in not different/random in my experience, although the name I've seen differs from the names(s) I have thus far seen published elsewhere. Almost ALL PIDs are assigned dynamically every time a machine restarts or a process goes through its full life cycle, no surprise here.

    Yes, of course.
    Monday, August 29, 2011 6:16 PM
  • Try to suspend the process if possible using process explorer, if they have a "buddy" process that watch each other they will notice the terminated one and start another.

    From what I understand sens32.dll is the loader. It instantiates this thing as a service. Then the service actually runs the worm code. If you kill it another gets started. While the articles are calling the service "6to4" I've had it running as "FastUserSwitchingCompatibility" on a Windows 7 client.

    Unfortunately, mine accidentally got cleaned so I don't have that copy to research any more. :-(

    Monday, August 29, 2011 6:33 PM
  • SOS!!!

    My system can not running normally, after the hardware detection, the screen will black. but the "safe mode" can access, I have clear the Sens32.dll and contents of offiline web pages, is anybody have the solution to resolve it?

    Wednesday, August 31, 2011 11:58 AM
  • After a few day's we haven't seen the virus back on our systems with the resolution mentiond above.

    Wednesday, August 31, 2011 12:58 PM
  • same here.  I had the subscriber run Microsoft Safety Scanner 1.0.3001.0 on their Win7 box and they told me that it detected 1 infection.  They did not confim what it was.  I also ran it in their 2003 VM.  It's been running a few days and no signs of infection.

    Looking at our incoming firewall logs, that is an entirely different story.  All 3 datacenters are pretty much showing a constant incoming storm of RDP scanning from all over the net.  much higher than normal.  It's being filtered out with the other 'noise'

    I consider the issue to be resolved.  thank you everyone for your assistance.


    BarrySDCA
    Wednesday, August 31, 2011 2:43 PM
  • We have a Server 2003 R2 infected with that. After following AD van Dijk's instructions where I stopped and disabled system event notification service, not being able to find the 6to4 key and deleted the Ias in System\WPA, pointed the sens.dll back to normal and rebooted the system totally crashed. I couldnt start it neither normally nor safe mode not even last known good configuration. I had to go through backup restore as windows repair wouldn't work either. After restoring the server I tried Microsoft's Safety Scanner which supposed to get rid of the threat. Well, it didn't. The only thing it din't like was VNC.Running netstat -nb tells me that one of the established connections is by svchost using RemoteAccess but I compared that with a healthy server and it looks to be OK. I understand that when I notice svchost connecting on 3389 that's morto.  I run  Symantec's PowerEraser but it did nothing. Still stuck with it as I'm writing this message

     

    BTW I wanted to add that the server has a very complex password and there is no other user with administrative priviliges on it.


    yaro




    Thursday, September 01, 2011 2:52 PM
  • Strange the server didn't start up.

    I assume the files %windows%\offline web pages\chache.txt and %system%\sens32.dll excist on you machine.

    you can do what i posted earlyer or:
    Start in safe mode.

    -Delete the files under %windows%\offline web pages\
    -Delete sens32.dll

    Regedit:
    change back:
    subkey: HKLM\SYSTEM\CurrentControlSet\Services\Sens\Parameters
    value: "ServiceDll"
    data: "<system folder>\sens.dll"

    Delete the complete key and everyting under it (we didn't see it on servers only on xp machines)
    HKLM\SYSTEM\CurrentControlSet\Services\6to4

    Clean the keys under not the folders! (Look if Ias and/or 6to4 is standing in one of the keys)
    HKLM\SYSTEM\WPA\

    services:
    If the serice Ias excist disable this. you can try to remove it.


    Thursday, September 01, 2011 9:13 PM
  • After a complete restore I went through your procedure again in safe mode. So far it looks like it works. Many thanks
    yaro
    Sunday, September 04, 2011 5:49 PM
  • Ignoring the obnoxious comment from ObiWan and reiterating that this thread is relevant and current (and not from 2007 as he suggested)...pleas review....http://forums.majorgeeks.com/showthread.php?p=1659242.

    This seems to specifically state the problem at hand. Has anyone has success in removing these files?

    Yes, sorry for the error, I overlooked that; on the other hand, removing the files isn't a solution; the box has been compromised and has a rootkit installed, this means that even if you remove those files, the attacker may have installed some backdoor on the system and may still be able to regain access to it; the only real way to trust such a compromised machine would be bringing it offline, cleaning it as much as possible, backing up whatever relevant data and then flattening it and rebuilding it from scratch but... paying attention to properly lock it down to avoid another attack leveraging the same "security hole" which was used for the current attack

     

    Monday, September 05, 2011 7:48 AM
  • And the plot thickens.  Although the customer agreed to block 3389 at the firewall and use the terminl services gateway moving forward, that has not been done yet.  After blockng all outbound access, I noticed a new user account, 'sys', was created and an inbound RDP connection was established from 178.162.174.77, logging in as this new user!


    Which means that the attacker has access to the system; again, bring the system offline, use a boot-cd like this one to run a general cleanup, proceed backing up whatever relevant data and then flatten the box and rebuild it from scratch; there's NO OTHER way to fix the issue and just removing some files or firewalling some ports won't allow you to TRUST that system

     

    Monday, September 05, 2011 7:55 AM
  • SOS!!!

    My system can not running normally, after the hardware detection, the screen will black. but the "safe mode" can access, I have clear the Sens32.dll and contents of offiline web pages, is anybody have the solution to resolve it?

    Read the following ... and no, it's not a joke, it's the ONLY way to really solve the issue


    http://technet.microsoft.com/en-us/library/cc512587.aspx

    http://technet.microsoft.com/en-us/library/cc512595.aspx


    Monday, September 05, 2011 8:00 AM
  • Microsot Safety Scanner detects the virus but it doesn't clean the System completly so it come's back after a wile if you don't clean manualy the reg keys.

    MSep doesn't clean the reg keys:
    HKLM\SYSTEM\CurrentControlSet\Services\6to4
    HKLM\SYSTEM\WPA\

    This was still so at 29 aug 2011 around 4 AM GMT +1

    Again, scanning the system that way is just one step; the scan/clean you can perform by running the MS Safety Scanner will just allow you to bring "down" the malware for a while... the time needed to backup whatever relevant data; then, to really cleanup the system you will need to perform a total reinstall from scratch, there's no other way to solve it and even if you'll remove files and stuff, you won't be able to tell if the system will be totally and really clean nor to trust it

     

    Monday, September 05, 2011 8:08 AM
  • A heads-up to everyone:

     

    Over the weekend, we detected another subscriber infected with Morto.  This was a BRAND NEW VM, 2003 R2 and fully patched with a very strong password.  The subscriber I believe has Win7.

    MS Safety Scanner DID NOT return any infection

    I verified tons of outgoing RDP, same symptoms.  This one also had an open port 80 connection to 208.92.165.96

     

     


    BarrySDCA
    Tuesday, September 06, 2011 4:06 PM
  • A heads-up to everyone:

     

    Over the weekend, we detected another subscriber infected with Morto.  This was a BRAND NEW VM, 2003 R2 and fully patched with a very strong password.  The subscriber I believe has Win7.

    MS Safety Scanner DID NOT return any infection

    I verified tons of outgoing RDP, same symptoms.  This one also had an open port 80 connection to 208.92.165.96

    What do you mean with "subscriber" ? Was that VM brought up on the same network on which the other compromised system was ?

    Again, if you didn't flatten/rebuild the compromised system and didn't check the other systems reachable on that network then there are probabilities that the malware is still sitting on your network and infecting new boxes as soon as they get connected, this may happen (for example) if the initial password used for the VM setup is a common one; the malware may be able to hit and infect the VM before you get in and change the password to a strong one

     

    Tuesday, September 06, 2011 4:23 PM
  • the previous system was reprovisioned as-new.  it's not spreading on our network.  we detect rdp floods very quickly and kill the IP.

     

    subscriber - we are an online service provider

     

    follow-up to new infection:  subscriber says they did indeed login one time from an XP machine.

    MS safety scanner did NOT detect this one

     


    BarrySDCA
    Tuesday, September 06, 2011 7:48 PM
  • the previous system was reprovisioned as-new.  it's not spreading on our network.  we detect rdp floods very quickly and kill the IP.

    I see... I just wonder if the reprovisioning also meant resetting the initial accounts/passwords to some "default", that may be the cause of the reinfection (just guessing, don't get me wrong)

    subscriber - we are an online service provider

    Got it, in such a case, also given that the MS Safety scanner was unable to flag the malware, I think you'd better directly contact Microsoft and have them work with you to investigate the issue and help you fixing it

    As for the issue and contacts, here are some resources

     
     
     
     
    which may be useful
    HTH

     

     

    • Edited by ObiWan Wednesday, September 07, 2011 8:36 AM
    Wednesday, September 07, 2011 8:35 AM
  • the previous system was reprovisioned as-new.  it's not spreading on our network.  we detect rdp floods very quickly and kill the IP.


    Forgot (sorry), a quick workaround to stop worm spreading could be adding a new RDP listener as described here and using whatever port (e.g. 50183) next, after checking that the RDP connection on the alt-port is working, filtering out (using the system firewall) port 3389/TCP so that the "blind-scan" from the worm will hit a closed port and the malware won't be able to spread; notice though that the above is just a workaround useful to prevent attacks from such "blind-scanners / bruteforcers" but it won't add any kind of security, if a machine has weak passwords, the security issues will still be present

     

    Wednesday, September 07, 2011 10:00 AM
  • you seriously don't think I am aware of changing the port option?  we do not have that luxury as a service provider.  And do you really think we would keep the same password?  As I demonstrated before, our passwords are reasonably strong and the VM was infected by RDP disk share.  As I said earlier, our network QUICKLY detects RDP hacking and kills the remote IP.  That is not a real problem here.

    I'm not asking you for help, I'm simply updating the community that there is a new one out there undetected by safety scanner.  The first subscriber's VM was detected by safety scanner.  not the second.

    thank you


    BarrySDCA
    • Edited by BarrySDCA Wednesday, September 07, 2011 3:04 PM
    Wednesday, September 07, 2011 3:00 PM
  • you seriously don't think I am aware of changing the port option?  we do not have that luxury as a service provider. 

    Well, that's up to you, if your customers are using weak passwords on some machines, that worm may hit them and the option of changing port is the only workaround you have at the moment, that's why I suggested it... and not just for you, but for anyone else reading this and trying to find a way to quickly patch the issue (again, not a definitive solution, that would be forcing complex password policy on all the boxes and also revising existing accounts and double checking credentials and permissions, but that would take time... and changing the port would give one some time to do it)

    And do you really think we would keep the same password? 

    As I demonstrated before, our passwords are reasonably strong and the VM was infected by RDP disk share. 

    I don't know, you may or may not, I'm not saying you're using the same password but then I can't know if you, in effect, do that; also, what makes you think that the VM was infected by RDP disk share and not by some other mean ?

    As I said earlier, our network QUICKLY detects RDP hacking and kills the remote IP.  That is not a real problem here.

    Which is good, having IDS/IPS in place helps, but given the fact that systems compromised by such a critter also contain backdoors (see that "sys account creation" in this discussion) allowing an attacker to regain access to the boxes, killing outbound RDP connection won't be a cure, you'll just be trying to deal with the effects but that won't have any impact on the cause

    I'm not asking you for help, I'm simply updating the community that there is a new one out there undetected by safety scanner.  The first subscriber's VM was detected by safety scanner.  not the second.

    Maybe you aren't, but again, I wrote the other message to try helping other people with the same issue quickly "plugging" the hole until they won't have time to perform a deep revision of their accounts

    All the best

     

    • Proposed as answer by Hélio Rodrigues1 Thursday, September 15, 2011 11:46 PM
    • Unproposed as answer by BarrySDCA Thursday, September 15, 2011 11:59 PM
    Wednesday, September 07, 2011 3:28 PM
  • Hi...

    I´m From Brazil and we have the same problem.

    First symptom: we note that the Internet bandwidth was being consumed, and it was necessary to reboot the Web server.

    After that we began to check  the network machine infected with a virus. We Turn each machine (60) of the switchs.
    Isolates the server (Windows Server 2003 R2) and the Internet server in the Switch. 

    After that, and nothing solved, we turned off the 2003 Server. Bandwidth consumption was normal.

    Turning on back the Windows Server, the use of internet has increased dramatically.

    Then we used a port scan and noticed that there are several attempts to connect to multiple servers on the Internet over port 3389. In one case, unable to access a Windows 2003 Server Enterprise which was being attacked by our server. Connect it via Terminal Service.


    So we changed our connection port Terminal Service to a higher (over 10,000). Virus stopped trying to leave by 3389 and began to walk out the door 80, consuming the entire Internet bandwidth.

    We started to kill all processes that were trying out the door 80, one by one, in certain ip to kill the process restarted the server alone. It happened 3 times. After restart, it began again to attack the port 3389.

    After that, to avoid formatting the server, did the procedure described by A D van Dijk (some posts ago).

    Everything is running smoothly so far...  But we still plan to format the server. 

    We still have a copy of SENS32.dll if someone wants to study.

    That's all



    Friday, September 16, 2011 12:03 AM
  • We still have a copy of SENS32.dll if someone wants to study.

    If possible, create a passworded zip containing the file (use "infected" as the password), upload the zip to some online storage and post the link; I'm curious to have a look at the critter ... even if it's just the "main payload" and not the whole malware

    Friday, September 16, 2011 8:04 AM
  • I sent some suspicious files to Symantec using their tool do you think they will come up with a solution for this w32.morto worm?
    Wednesday, September 21, 2011 3:08 PM
  • malware byte might do the trick. Run the scanner and use Fileassassin to remove sens32.dll. Then reboot the server.
    • Proposed as answer by Avi - Sofnet Friday, September 23, 2011 9:01 PM
    • Unproposed as answer by Avi - Sofnet Friday, September 23, 2011 9:06 PM
    Friday, September 23, 2011 6:47 AM
  • Friday, September 23, 2011 9:08 PM
  • Hello BarrySDCA,

    The behavior you are describing sounds very much like the Morto.A malware as others have suggested in this forum. Here is a technical write-up our analysts at the Microsoft Malware Protection Center have on this threat: http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Worm%3AWin32%2FMorto.A

    I also see that there are reports of reinfection after cleaning the aforementioned malware, so there are a few things to consider here:

    1.  Microsoft detects and removes the Morto.A family/variant. You can use the Microsoft Safety Scanner to clean this particular malware as well as all other known malware that Microsoft has definitions for. The MS Safety Scanner can be downloaded from: http://www.microsoft.com/security/scanner/en-us/default.aspx

    2.  If you are seeing a reinfection of this, or any malware, it is possible that a rootkit and/or trojan dropper still exists on the system. Microsoft is offering a beta version of a bootable scanning utility that will allow you to boot into a WinPE environment and scan the file system while it is offline thus preventing the potential rootkit from loading and giving you a better chance of finding it. Please see the Standalone System Sweeper at: http://connect.microsoft.com/systemsweeper

    3.  While your primary point of contact is your AV vendor for mitigating malware events, Microsoft is dedicated to assisting customers that have been infected with malware. You are always welcome to open a case with Microsoft Support free of charge. For professional customer's, please visit the Microsoft Virus Solution and Security Center for resources and tools to keep your PC safe and healthy. If you are having issues with installing the update itself, visit Support for Microsoft Update for resources and tools to keep your PC updated with the latest updates. 

    Please feel free to ping me with any additional questions and/or concerns you may have.


    Jess Huber [MSFT] | Sr. Support Engineer | CSS Security

    • Edited by Jess Huber Friday, October 07, 2011 7:14 PM
    • Proposed as answer by Jess Huber Friday, October 07, 2011 7:26 PM
    • Edited by Elytis ChengModerator Friday, April 06, 2012 6:11 AM PCSafety Center update
    Friday, October 07, 2011 7:13 PM
  • Not sure, is this a new version of Morto, but my FEP with new definitions is alarming me all the time about C:\Windows\Offline Web Pages\ new files there. I have a weak password policy. FEP detects this as Morto!dat so I´m not sure what version this really is.
    Friday, May 04, 2012 7:05 AM