Another possibility is the use of this tool as well: http://www.sensepost.com/labs/tools/pentest/reduh (Reduh)
Jerry je...@jdixon.com On Fri, Jan 13, 2012 at 12:02 PM, Mark Keymer <m...@viviotech.net> wrote: > Hi, > > We have had 2 of the below hit us this week. First time was apx 11:20am > 1/10/2012 (PST). The 2nd was 1/12/2012 (Yesterday) 4:45pm. We had done some > research and had already planed to switch to Network Level Authentication > (NLA) as it looks like that would help with the screen not getting dumped. > Unfortunately we had not done the change to that yet as we were getting > looking for and found a new RDP client on linux that would support it. > However last night we did start doing the changes to NLA. > > I am not saying NLA is a fix or that it is the best option. Just one of > the things we are trying. When we can, locking down access to the RDP port > I think would be best. > > Ohh, as for the destination. The first day was to 221.251.194.42. > Yesterday was for 115.236.185.167. > > Sincerely, > > Mark Keymer > > > On 1/13/2012 4:36 AM, James Braunegg wrote: > >> Hey All, >> >> Just posting to see if anyone has seen any strange outbound traffic on >> port 3389 from Microsoft Windows Server over the last few hours. >> >> We witnessed an alarming amount of completely independent Microsoft >> Windows Servers, each on separate vlan and subnets (ie all /30 and /29 >> allocations) with separate gateways on and completely separate customers, >> but all services were within the same 1.x.x.x/16 allocation all >> simultaneously send around 2mbit or so data to a specific target IP address. >> >> The only common link was / is terminal services port 3389 is open to the >> public. Obviously someone (Mr 133t dude) scanned an allocation within our >> network, and like a worm was able to simultaneously control every Microsoft >> Windows Server to send outbound traffic. >> >> Microsoft Windows Servers within the 1.x.x.x/16 allocation which were >> behind a firewall or VPN and did not have public 3389 access did not send >> the unknown traffic >> >> Would be very interested if anyone else has seen this behavior before ! >> Or is this the start of a lovely new Zero Day Vulnerability with Windows >> RDP, if so I name it "ohDeer-RDP" >> >> A sample of the traffic is as per below, collected from netflow >> >> Source Destination Application Src >> Port Dst >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 51534 >> TCP >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 52699 >> TCP >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 60824 >> TCP >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 51669 >> TCP >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 49215 >> TCP >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 62099 >> TCP >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 65429 >> TCP >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 51965 >> TCP >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 50381 >> TCP >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 59379 >> TCP >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 58103 >> TCP >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 59514 >> TCP >> x.x.x.x/16 58.162.67.45 ms-wbt-server 3389 58298 >> TCP >> >> This occurred around 10:30pm AEST Friday the 13th of January 2012 >> >> We had many other Microsoft Windows Servers in other 2.x.x.x/16 IP ranges >> which were totally unaffected. >> >> Kindest Regards >> >> James Braunegg >> W: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 >> E: >> james.braun...@micron21.com<**mailto:james.braunegg@**micron21.com<james.braun...@micron21.com>> >> | ABN: 12 109 977 666 >> >> [Description: Description: Description: M21.jpg] >> >> This message is intended for the addressee named above. It may contain >> privileged or confidential information. If you are not the intended >> recipient of this message you must not use, copy, distribute or disclose it >> to anyone other than the addressee. If you have received this message in >> error please return the message to the sender by replying to it and then >> delete the message from your computer. >> >> >> > > -- Jerry je...@jdixon.com
