?
Solved

deny local logon

Posted on 2016-10-18
12
Medium Priority
?
161 Views
Last Modified: 2016-10-19
from the results of a recent pen test, despite us having a domain password policy that adheres to Microsofts own recommendations, the security testers flagged up some powerful accounts (domain admins) with easily compromised passwords. Whereas we have strengthened these as per their recommendations, these accounts had been subject to a GPO that denies local logon to any system .they appear to link to service accounts which clearly shouldn't be domain admins but were setup by an old 3rd party who managed IT support.

My question is, out of curiosity, is that our security team seem to think the fact these accounts are prevented form local logon, vastly reduces the risk if these accounts were compromised. what is your view, I presume there are still other methods that could be used if these accounts were compromised, to access systems and resources (e.g perhaps used to map a network drive to a system with sensitive info). or do you agree with our security team that the fact the accounts are subject to GPO that denies local logon - that therefore reduces the impact if someone guessed these supposedly weak passwords.
0
Comment
Question by:pma111
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
  • 2
  • +2
12 Comments
 
LVL 85

Accepted Solution

by:
oBdA earned 1004 total points
ID: 41848423
Well, it reduces the risk a bit, but not 'vastly'. "Deny local logon" just means that: local logon. It doesn't prevent network logon, exploiting shares, it doesn't prevent remote management using WMI or whatever else is available, it doesn't prevent creating new admin account(s) that are allowed to logon locally, ...
Look at it this way: if these accounts wouldn't be able to actually use their credentials, then they wouldn't need to be in the Domain Admins group to start with.
0
 
LVL 64

Assisted Solution

by:btan
btan earned 332 total points
ID: 41848474
A privileged user with weak password will be one of the weakest link that can be compromised and this risk is greater. In fact, the denial should be remote access instead of local logon for privileged users. Attacker penetrate and move laterally to other connected servers easily if they allow remote access and move vertically easily if local logon allows such service account to be used - compromised servers and services in total give greater damages.

If you take CVSS as gauge, the score is higher (more severe) depending on the "remoteness" of the attacker relative to the vulnerable component.
That is, the more remote an attacker is to the vulnerable component (in terms of logical and physical network distance), the greater the Base score will be.

Further, this metric now distinguishes between local attacks which require local system access (such as with an attack against a desktop application) and physical attacks which require physical access to the platform in order to exploit a vulnerability (such as with a firewire, USB, or jailbreaking attack).
So a better posture is to deny user from interactively login instead - That is to restrict the machines to which a user can log on interactively. Domain administrators can restrict to which domain machines a domain user can log on interactively by using the AD “Log On To…” user account property.

The scenario that is serious is instead the use of local accounts for remote access e.g.
when an administrative local account has the same user name and password on multiple machines, an attacker with administrative rights on one machine can easily obtain the account’s password hash from the local Security Accounts Manager (SAM) database and use it to gain administrative rights over the other machines using “pass the hash” techniques.
0
 
LVL 42

Assisted Solution

by:Adam Brown
Adam Brown earned 332 total points
ID: 41848492
Local logon is the most secure logon method available. Denying local logon while allowing Network logon is, in my opinion, not an increase of security in any way. Local Logon requires physical access to a system, so if someone gets to a point where they can utilize the Local Logon right, they have already gotten to a point that is well beyond all your other security measures. The vast majority of attacks will come from remote locations, and denying local logon will not do anything to stop these kinds of attacks, and having domain admin accounts that have network logon, remote desktop logon, and other logon capabilities with weak passwords is significantly more dangerous than domain admins with local login rights.

For instance, a domain admin account without local logon access will prevent someone from logging in when they're on site with that account, but then they just need to log in to another computer using RDP and that account and they have full Network access immediately.

Even allowing "Log on as batch" can easily result in compromised systems, since it allows a user to create a script that generates a new domain admin account without login restrictions and run it with higher privileges using the Scheduled Tasks feature.

Basically, you will want to make sure your service accounts are only granted the permissions they need and have secure passwords. Just denying local login to them provides a 0% reduction of risk.
0
Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

 
LVL 56

Expert Comment

by:McKnife
ID: 41848500
I have a question for you: how did the pentesters find out that these account passwords were "easily compromisable"? They should not even be in the position to find that out. Or did you tell them how the passwords are / what rules you follow?
0
 
LVL 3

Author Comment

by:pma111
ID: 41848581
I presume they used a utility that did some sort of word list attack against any accounts they enumerated.
0
 
LVL 56

Assisted Solution

by:McKnife
McKnife earned 332 total points
ID: 41848604
Ok, so again: how could they manage to even try these passwords?  Let's say they have been granted access to a domain client pc with a standard restricted domain user and they could enumerate all accounts that are domain admins:
net group domain-admins /domain

Open in new window

They get names, let's say SuperJoe.

How would they go about to crack SuperJoes password or at least determine it is a weak one? This is something they need to tell you - there is your problem.
0
 
LVL 42

Expert Comment

by:Adam Brown
ID: 41848773
McKnife, there are two ways you could determine if administrative accounts have weak passwords:
1. Examine domain password requirements. If they are not set to require complexity/sufficient length and there is no FGPP set up to increase the requirements for administrators, it is a safe assumption that the passwords for those accounts are not strong.

2. If a utility is able to act in the context of the system account on a Domain controller, it can examine the AD database to obtain the password hashes that are stored there for each account (acting in the system context is very easy if you have administrative access already). Once you have the password hashes for all domain accounts, you can then compare those hashes with a rainbow table of common/weak passwords. This type of thing is very difficult to pull off without complete access to the environment, but if that is granted to a security auditing team they can do so in a matter of minutes without difficulty. This is most likely what they did to determine the password strength of the accounts in question.
0
 
LVL 56

Expert Comment

by:McKnife
ID: 41848845
Adam, you don't have to tell me, I know such things. But still, I don't quite agree:
knowing the pw policy does not let us assume anything. These passwords could be weak, but who says most admins are lazy? I wouldn't. Also, having system access to the DC? How would the pentesters not mention this? It cannot be that pma's company granted them that level of access, this would be a funny concept for a pentest.

I am always trying to give sound advice. We need more info about what the PTs said and did, otherwise this will lead nowhere.

So to continue on my question addressed to pma "How would they go about to crack SuperJoes password or at least determine it is a weak one?"
You can't just start a script that goes guessing passwords even if you were allowed to use that account for local logons. Immediately, that account would be locked out. Guessing would be over. To get a judgement about the quality of the password, one would at least need the hash of it, so those pentesters did either tell you something different and you completely misinterpreted it, or they had a go at the pw hashes. Obtaining a hash is only possible if you have admin access to a machine where such a domain admin account is used on.

Ask the pentesters or this will lead nowhere.
0
 
LVL 64

Expert Comment

by:btan
ID: 41849303
Should have enforce 2FA for any remote access esp of those for admin access remotely. The newer OS vetsion have a better controls over such admin access exploiting via the PtH attack
Programs are prevented from leaving credentials in memory after a user logs out


Allows Remote Desktop Protocol (RDP) connections without putting the user's credentials on the remotely controlled computer

A new Protected Users group, with member's credentials that can't be used in remote PtH attacks
0
 
LVL 3

Author Comment

by:pma111
ID: 41849557
to clarify, a weak password in their view, is still one which meets minimum characters length of 10 with complexity enabled, as per the policy. But this doesn't prevent selections such as Administrator01 (that wasn't an example, but for arguments sake). I believe this is called a virtual brute force when they try a selection of common passwords against all accounts - which then doesn't lock them due to account lockout policies.
0
 
LVL 56

Expert Comment

by:McKnife
ID: 41849573
I have no idea what a "virtual brute force" should be.
What was it that the pentesters said? Was it, as Adam assumed, that they just judged the password policies that were applied to the domain admins or was it the password itself? If the latter, how did they do that?
0
 
LVL 64

Expert Comment

by:btan
ID: 41849763
Reading what the pentester as "common words", I deemed they are referring to dictionary based brute force since it is using common word. Password complexity policy is required.
0

Featured Post

Ransomware Attacks Keeping You Up at Night?

Will your organization be ransomware's next victim?  The good news is that these attacks are predicable and therefore preventable. Learn more about how you can  stop a ransomware attacks before encryption takes place with our Ransomware Prevention Kit!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This process allows computer passwords to be managed and secured without using LAPS. This is an improvement on an existing process, enhanced to store password encrypted, instead of clear-text files within SQL
Compliance and data security require steps be taken to prevent unauthorized users from copying data.  Here's one method to prevent data theft via USB drives (and writable optical media).
Attackers love to prey on accounts that have privileges. Reducing privileged accounts and protecting privileged accounts therefore is paramount. Users, groups, and service accounts need to be protected to help protect the entire Active Directory …
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.
Suggested Courses

801 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question