Jump to content


Photo

Windows7 Workstation name


  • Please log in to reply
38 replies to this topic

#21 jtb2035

jtb2035

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 25 April 2016 - 03:53 PM

I haven't seen anymore activity with in our environment and was not able to open a packet capture fast enough to see where it was coming from.

 

3389 better not be published.



#22 primags

primags

    Newbie

  • Members
  • Pip
  • 3 posts

Posted 25 April 2016 - 07:48 PM

@jtb2035 - maybe try an external port scan and see what you get...We have 3389 published because of a legacy terminal server.



#23 phil4

phil4

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 26 April 2016 - 09:00 PM

I found this thread when trying to find anything further about this, as I have, I think, the same problem.

 

It started late last year and the workstation was always identified as Windows7,  which was odd since while we didn't routinely name workstations, we had none that matched that.  No IP in the logs so all hit and miss.

 

The usernames tried were as you'd expect someone who's no clue,  Administrator, scanner, business, back office, cafe.

 

We thought we'd narrowed it down to a single machine, ESET hadn't and didn't spot anything, but I've rebuilt it back to bare metal twice since, and still have random flare-ups.  Sometimes it can be a week or more between attempts, sometimes, many the same day.  Each time the logs show them trying lots of accounts, and passwords, and then it'll stop.

 

We have various things exposed to the outside world, most don't use domain accounts, but some do.  RDP is on a non-standard port, but if they'd tries one of the website subdirectory they'd have found Windows authentication.

 

We've since had a second round at another location.  This one is better tied down, with next to no external access.  But again if you go to a certain subdirectory, you'll hit windows auth.  I'm thinking SSRS config for example.  With this one we've also briefly seen FreeRDP as a workstation name.

 

So far, I've been doing what I can do rename account so they can't be attacked, it's working quite well.

 

I've still no idea what it is, but they seem quite prepared to try non-standard ports, and website subdirectories to try.



#24 bf@ua

bf@ua

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 26 April 2016 - 09:55 PM

We are going to shutdown the remaining RDP PC clients (we've allowed it for ease of use with some legacy clients and some Linux / Android RD client instances that didn't have a gateway option) and enforce the use of the RD Gateway service via SSL. This article (Search -> building-a-remote-desktop-gateway-rdg-rd-gateway-server)  is a good start just remember to allow the "NAP" service to auth & read the AD (find a DC) and run this service on any 2008R2 with exposed services to the internet.

 That way you can minimize foot print down to nothing, we'll still have a couple servers open but something like the product "RDP Guard" (free trial)" can shore that up to mitigate that angle.



#25 jcail

jcail

    Newbie

  • Members
  • Pip
  • 6 posts
  • Gender:Male
  • Location:Atlanta, Georgia

Posted 27 April 2016 - 11:06 AM

Sadly, it was 3389.  I found one box with it, and the rule was misconfigured (allow any instead of 443).  That definitely ended the problem here.  

Check inbound traffic for activity on 3389 - it should be blocked/dropped.


Jesse Cail, CISSP

Security Engineer


#26 adg

adg

    Newbie

  • Members
  • Pip
  • 5 posts

Posted 14 May 2016 - 11:33 PM

Hello

 

Anyone could tell me if any of the following patches from Microsoft is installed on domain controllers?

 

 

MS11-058

MS14-066

MS16-047

KB2705219  -- ms12-054.aspx
 

I am discussing this case, with several security specialists. thanks



#27 bf@ua

bf@ua

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 15 May 2016 - 07:18 AM

 A quick glance for articles dated 2012, 2014 & 2016, I would suggest any DC 2008/2008R2 & up that would be affected would have these installed. Also, even though this topic is based on RDP port scanning, even without DC's being exposed to external scanning, if people are going to RDP into them, I would think most have changed the RDP port to anything but 3389.



#28 adg

adg

    Newbie

  • Members
  • Pip
  • 5 posts

Posted 16 May 2016 - 04:24 AM

bf@ua

which 
articles you have seen  about this attack?

 

in our environment we have not published out the rdp port. someone might mitigate this attack?



#29 bf@ua

bf@ua

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 16 May 2016 - 02:53 PM

 Nothing too specific, I was just mentioning that internally, even when not publishing, it's a known port to scan. There is always a possibility a mobile device returning to, or PC,  in the internal network could get compromised & become a scanning bot. I am simply was suggesting to have DC's RDP port altered to something else as an additional layer of obfuscation / mitigation (seldom are routine tasks accomplished on a live DC console). Seems about every two or so years there is a specific flaw in the RDP protocol & you see public hacking / scanning attempts looking for unpatched systems & they typically subside. These new power scanning bots that seem to be able to scan subnets and run attempted logins are a new level of sophistication & thus requires a bit more of our attention to ensure it's a failed endeavor.



#30 adg

adg

    Newbie

  • Members
  • Pip
  • 5 posts

Posted 17 May 2016 - 03:32 AM

bf@ua

 

Is true!!.

Do you have Windows 2008 and 2008R2 or Windows 2012 in your enviroment?

 i would like to know if you installed this path  in your Domain Controller.

 

MS11-058

MS14-066

MS16-047

KB2705219  -- ms12-054.aspx
 
Thanks!


#31 bf@ua

bf@ua

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 17 May 2016 - 03:45 AM

 MS11-058, MS12-054, MS14-066 & MS16-047. 2008R2 environment, that MS11-058 is post 2008R2 SP1 and I suspect all R2 environments would have the remainder of patches installed. The MS08 is pre "R2".



#32 neoo57

neoo57

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 18 May 2016 - 01:01 PM

Hey There

 

I too have this same issue with the Window7 computer hitting hit few various accounts scanner, support etc... I was just wondering if anyone was able to find some inbound IP's that can be blocked in the firewall?



#33 bf@ua

bf@ua

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 18 May 2016 - 01:08 PM

 I tried at the start to block some ranges (Amsterdam - China) but it is simply too wide spread & constant, it really geared up in the last couple months. I also trialed RDP Guard but their support in response to a technical question left me a little tepid in recomending their product, worth a trial though.



#34 adg

adg

    Newbie

  • Members
  • Pip
  • 5 posts

Posted 18 May 2016 - 03:47 PM

the best practice is to make a sniffer of these connections in the affected computers.
Someone consulted with ESET, Symantec, Sophos, ETC about this attack?
sellers may have information about this attack?


#35 bf@ua

bf@ua

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 18 May 2016 - 03:56 PM

 I've looked to see if there any signatures for IPS based systems, doesn't seem anyone has found a solid solution. yes IPS may detect an exploit but not the type of failed login attempts this method is doing.



#36 bisser.todorov

bisser.todorov

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 25 May 2016 - 02:40 PM

So, I had the same problem - Administrator's account was locked out a couple of times and the Caller Computer name was FreeRDP or Windows7 and nothing more. What I did to obtain more information was to enable debug logging for the Netlogon service - here you can find how. And few minutes after I got the information I needed in the log file C:\Windows\debug\netlogon.log in this format:

05/24 11:09:52 [LOGON] DOMAINNAME: NlPickDomainWithAccount: scan: Algorithm entered. UPN:0 Sam:1 Exp:0 Cross: 0 Root:1 DC:0
05/24 11:09:52 [LOGON] DOMAINNAME: SamLogon: Transitive Network logon of (null)\scan from Windows7 (via DEV01) Returns 0xC0000064
05/24 11:09:54 [LOGON] DOMAINNAME: SamLogon: Transitive Network logon of (null)\scan from Windows7 (via DEV01) Entered
05/24 11:09:54 [LOGON] DOMAINNAME: NlPickDomainWithAccount: scan: Algorithm entered. UPN:0 Sam:1 Exp:0 Cross: 0 Root:1 DC:0
05/24 11:09:54 [LOGON] DOMAINNAME: SamLogon: Transitive Network logon of (null)\scan from Windows7 (via DEV01) Returns 0xC0000064
05/24 11:09:55 [LOGON] DOMAINNAME: SamLogon: Transitive Network logon of (null)\scan from Windows7 (via DEV01) Entered
05/24 11:09:55 [LOGON] DOMAINNAME: NlPickDomainWithAccount: scan: Algorithm entered. UPN:0 Sam:1 Exp:0 Cross: 0 Root:1 DC:0
05/24 11:09:55 [LOGON] DOMAINNAME: SamLogon: Transitive Network logon of (null)\scan from Windows7 (via DEV01) Returns 0xC0000064
05/24 11:09:56 [LOGON] DOMAINNAME: SamLogon: Transitive Network logon of (null)\ricoh from Windows7 (via DEV01) Entered
05/24 11:09:56 [LOGON] DOMAINNAME: NlPickDomainWithAccount: ricoh: Algorithm entered. UPN:0 Sam:1 Exp:0 Cross: 0 Root:1 DC:0
05/24 11:09:56 [LOGON] DOMAINNAME: SamLogon: Transitive Network logon of (null)\ricoh from Windows7 (via DEV01) Returns 0xC0000064
05/24 11:09:57 [LOGON] DOMAINNAME: SamLogon: Transitive Network logon of (null)\ricoh from Windows7 (via DEV01) Entered
05/24 11:09:57 [LOGON] DOMAINNAME: NlPickDomainWithAccount: ricoh: Algorithm entered. UPN:0 Sam:1 Exp:0 Cross: 0 Root:1 DC:0
05/24 11:09:57 [LOGON] DOMAINNAME: SamLogon: Transitive Network logon of (null)\ricoh from Windows7 (via DEV01) Returns 0xC0000064
05/24 11:09:58 [LOGON] DOMAINNAME: SamLogon: Transitive Network logon of (null)\shipping2 from Windows7 (via DEV01) Entered

In my case, a DEV machine with enabled NTLM authentication was exposed directly to Internet and someone tried to connect/hack to it :) 



#37 unity421

unity421

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 07 June 2016 - 06:41 PM

This is great information.  Has anyone determined if this is a bot / worm?  Thanks

 

I'm thinking this is similar to the Morto worm. https://thebl4ckh4t....ord-taking.html



#38 adg

adg

    Newbie

  • Members
  • Pip
  • 5 posts

Posted 10 July 2016 - 06:01 PM

Hi, i found it. this is 3389 rpd exposed to internet. 

Check the netlogon.log using dbflag in the domain Controllers.

 

It´s not the morto Worm.

Attackers host names:  Windows7. FreeRDP. ECC7



#39 kboogie

kboogie

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 02 July 2018 - 10:23 PM

Looking for help with Linux Add On regular expressions errors.  Anyone getting this error.

 

Parsing message (SUPERUSERDO). <81>






0 user(s) are reading this topic

0 members, guests, anonymous users