Jump to content


Photo

Windows7 Workstation name


  • Please log in to reply
38 replies to this topic

#1 andybell007

andybell007

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 01 December 2015 - 05:08 PM

Hi All

 

We have had some random bulk lockouts of accounts over night a few times lately.

 

Netwrix Account Lockout Examiner shows them as locked out however it only shows the workstation name as Windows7.

 

Can someone tell me if this is a generic name for a Windows 7 machine that Netwrix Account Lockout Examiner is unable to tell us the correct name of? or if it's actually the name of the machine?

 

Thanks

 

Andy



#2 dsmirnov

dsmirnov

    Advanced Member

  • Root Admin
  • PipPipPip
  • 58 posts
  • Gender:Male

Posted 01 December 2015 - 07:24 PM

andybell007,

 

Account Lockout Examiner takes the Workstation name from the Caller computer name of the Lockout event.

https://www.netwrix.com/kb/1559

 

It does not specify any generic values, so if something is specified in Workstation, it is the name of the machine.



#3 jjsumption

jjsumption

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 28 December 2015 - 05:59 PM

We have been experiencing the same situation over the last few days. Windows7 as the workstation name, yet there is no Windows7 on the domain that we can find.



#4 ABCStore

ABCStore

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 09 February 2016 - 05:46 PM

Exactly the same situation. Where does this mysterious "Windows7" come from?



#5 Bill75080

Bill75080

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 26 February 2016 - 03:30 AM

Is there no answer to this issue? I am getting lots of activity from the workstation Windows7 yet there is no Windows7 workstation.



#6 primags

primags

    Newbie

  • Members
  • Pip
  • 3 posts

Posted 15 March 2016 - 07:10 PM

We are seeing the same exact thing in our org.  In addition to "Windows7" being the computer name causing the lockouts, we are seeing "FreeRDP" and "debian-8-32bit" locking out the same accounts that are being locked by "Windows7".  None of these computer names are resolvable.

 

The accounts being locked out are generically named accounts, like "Support" or "Scanner" or "Monitor", which lead me to believe its some kind of malware in our environment that is trying various generic account names.

 

If anyone has more info on this, please respond to this thread.



#7 jtb2035

jtb2035

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 28 March 2016 - 02:57 PM

  • Has anyone got any info on this? Looks like the computers are off a domain, but where are they coming from?


#8 jtb2035

jtb2035

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 29 March 2016 - 09:32 PM

We are seeing the same exact thing in our org.  In addition to "Windows7" being the computer name causing the lockouts, we are seeing "FreeRDP" and "debian-8-32bit" locking out the same accounts that are being locked by "Windows7".  None of these computer names are resolvable.

 

The accounts being locked out are generically named accounts, like "Support" or "Scanner" or "Monitor", which lead me to believe its some kind of malware in our environment that is trying various generic account names.

 

If anyone has more info on this, please respond to this thread.

bump



#9 thakkarj

thakkarj

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 01 April 2016 - 08:04 PM

Does anyone know why a workstation named \\freerdp would appear?

It's locking a domain account however \\freerdp does not appear to be a computer, workstation on the network?

Any easy way to track down?  Does Netwrix provide location IP of the device that is causing the issue.

Basically, I need more information on workstation named \\freerdp

Any ideas?



#10 jtb2035

jtb2035

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 05 April 2016 - 09:17 PM

I suspect it is malware on a machine. Do you have any outside access... such as webmail or vpn access?



#11 bf@ua

bf@ua

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 06 April 2016 - 05:56 PM

 This is interesting, we are also getting hammered with Windows7 & FreeRDP stations (no debian-8-32 though). There is a product called "RDPGuard", I am thinking of setting that up (trial software) on a couple PC's as HoneyPots that perhaps can log the IP address from these stations attacking them.

 

 



#12 jtb2035

jtb2035

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 08 April 2016 - 06:54 PM

Please let me know if you find anything and I will do the same



#13 bf@ua

bf@ua

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 08 April 2016 - 07:28 PM

 Well the last round of heavy intensive hammering was from the far east (221.203.142/24) but I certainly don't want  to brand the entire subnet as hostile and there are plenty of global attempts that make it irresponsible to accuse one subset of offending traffic as the point of all problems. That being said, this time, it is (was) these IP's that were hammering for RDP & SSH, so I will block the class C subnet for a month. Next time I'm sure it'll come from another point on the globe. Unfortunately, I'm located in a place where there is excess travel and global access back to a variety of services is an expected service. So the concept of "banning" ranges long term isn't an option and we have managed to reduce our exposed footprint quite a lot with various gateway features and security measures.



#14 jcail

jcail

    Newbie

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

Posted 18 April 2016 - 01:17 PM

Seeing the same activity here from workstations Windows7 and FreeRDP - Also seeing workstation JC1.

 

Did blocking the IP Range 221.203.142/24 work?  Looking for those IPs now


Jesse Cail, CISSP

Security Engineer


#15 bf@ua

bf@ua

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 18 April 2016 - 01:27 PM

 Briefly, but now seeing a lot from 31.44.191.x & 91.186.8.x . I think the reason the names are the same is it is some canned script tool that no one bothers to change when they run it. I am still on the trial version of this RDPGuard; but the honeypot idea does manage to capture who is trolling, if I could just find a way to populate the firewall easy via the software's logging. It's not cost effective (realistic) to buy software like this for a mass amount of machines.



#16 jcail

jcail

    Newbie

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

Posted 18 April 2016 - 05:58 PM

Thanks for the update - I didn't see any instance in or out of the IP ranges on the original post.  I set Netwrix up to alert on any change to the account that they're attempting to access, and am running wireshark on the targeted DC.  I managed to capture one hit, so now at least I have a suspect client.  Starting that process over to see if I can confirm those findings.  I'll do another search for the batch of IPs you just posted.  I'd tend to agree that it is a canned bit of script based off the commonality of the accounts & workstation names.  If I can confirm my findings, I'm going to get in touch with my CERT and ship them the hard drive.  I'm monitoring this thread, and will post any updates I have.


Jesse Cail, CISSP

Security Engineer


#17 jcail

jcail

    Newbie

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

Posted 18 April 2016 - 06:04 PM

Domain lookup has those IPs already listed as UK, Ukranine & China.  The usual suspects??


Jesse Cail, CISSP

Security Engineer


#18 jtb2035

jtb2035

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 25 April 2016 - 02:55 PM

@jcail " If I can confirm my findings, I'm going to get in touch with my CERT and ship them the hard drive."

 

Are you seeing this coming from inside?

 

Thanks



#19 jcail

jcail

    Newbie

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

Posted 25 April 2016 - 03:09 PM

@jtb2035  Unfortunately not, and monitoring packet captures is not my idea of good time.  I caught it once from a workstation, and hoped to catch it again.  SInce I haven't, I went ahead and had that workstation wiped as a precaution, but I'm still seeing it in the environment.  I opened a case with Netwrix since multiple people were reporting the issue, and their reply was "Netwrix only pulls what it sees from the Windows Logs".  Find anything useful / new in your environment?


Jesse Cail, CISSP

Security Engineer


#20 primags

primags

    Newbie

  • Members
  • Pip
  • 3 posts

Posted 25 April 2016 - 03:13 PM

From what we are seeing in our environment, it is caused by external machines trying to hit against devices in our domain that are open on 3389 (RDP).

 

I haven't seen anything that I can verify as internal yet.  If you have port 3389 open to the internet, that may be your cause.






0 user(s) are reading this topic

0 members, guests, anonymous users