3

While testing our Windows Domain Controller (Server 2012 R2), I was able use the Linux utility rpcclient to enumerate user accounts and groups via a Null Session (see output below).

Checking the Windows Registry keys on the DC, I confirmed that:

  • HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous = 0
  • HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM = 1
  • HKLM\System\CurrentControlSet\Control\Lsa\EveryoneIncludesAnonymous = 0

Testing the same rpcclient commands against a lab environment Server 2012 R2 DC with the exact same three Registry settings resulted in a "NT_STATUS_ACCESS_DENIED" message, as expected.

Putting aside the issue of having Null Sessions enabled in the first place... My understanding is that a value of "1" for the "RestrictAnonymousSAM" key should disable the ability to enumerate users and groups via a Null Session, so why am I still able to enumerate user information using rpcclient? Also, if the RestrictAnonymousSAM key is insufficient, what other changes are necessary to completely disable user and group enumeration via Null Sessions?

root@linuxbox:~# rpcclient -U "" {DC IP address}
Enter 's password: {empty}
rpcclient $> querydispinfo
index: 0xad08 RID: 0x122a acb: 0x00020011 Account: 000003   Name: User1 Desc:  
index: 0xab1d RID: 0x1159 acb: 0x00000010 Account: 000004   Name: User2 Desc:  
index: 0xabdc RID: 0x65c acb: 0x00000010 Account: 000009    Name: User3 Desc: 
...[snip]...
rpcclient $> enumdomusers
user:[Administrator] rid:[0x1e5]
user:[Guest] rid:[0x1e6]
user:[krbtgt] rid:[0x1e7]
...[snip]...
rpcclient $> enumalsgroups builtin
group:[RDS Management Servers] rid:[0x252]
group:[Hyper-V Administrators] rid:[0x253]
group:[Access Control Assistance Operators] rid:[0x254]
...[snip]...
rpcclient $> enumalsgroups domain
group:[RAS and IAS Servers] rid:[0x229]
group:[Allowed RODC Password Replication Group] rid:[0x24c]
group:[Denied RODC Password Replication Group] rid:[0x24d]
...[snip]...
userN071337
  • 31
  • 2

2 Answers2

2

I've recently performed a detailed experimental analysis on what causes the null session user enum to work and to fail. For anyone else trying to reproduce the vulnerable behavior, this is what I found:

  1. On newly deployed domain controllers starting from win2008R2 using the default configuration the user enum is not possible - this is what caused failure to reproduce vulnerable behavior in the original question (the attack does not work in the lab environment).
  2. In order to reproduce the vulnerable behavior one must add "ANONYMOUS LOGON" group to "Pre-windows 2000 compatible access" domain group. On default win AD deploy in 2012R2/2008R2, after this the enumdomusers starts to work. By default on new setups this group contains only "Authenticated Users" and on win2003 this group used to contain "ANONYMOUS LOGON" (see http://index-of.es/Windows/win_net_srv.pdf, 4.7.13). That's why on some real AD setups that progressively migrated from win 2003 to 2008 and then 2012, this group still contains "ANONYMOUS LOGON".

All in all, there are two ways to mitigate the vulnerability:

  1. Using GPOs 'Network access: Restrict anonymous access to named pipes and shares' (set to Enabled) and 'Network access: Named pipes that can be accessed anonymously' (Set to empty list).
  2. Remove "ANONMOUS LOGON" from "Pre-windows 2000 compatible access" domain group.

Optimally one should do both.

webpentest
  • 21
  • 2
1

From technet: https://technet.microsoft.com/en-us/library/jj852184(v=ws.11).aspx

This policy setting has no impact on domain controllers.

CGretski
  • 151
  • 6