Solved

external domain coverage

Posted on 2013-10-30
1
155 Views
Last Modified: 2013-11-14
I am trying to do some risk assessment work on the impact of having a weak domain password associated with a domain account. A 3rd party assessment found some domain accounts had weak passwords. Typically we would look at this as an internal only security issue, i..e only people with physical access to the offices would be able to exploit it. But I wondered what kind of external services would rely on domain passwords? Can you provide some examples where a weak domain password would possible be exploitable by someone outside your AD - i.e. from the Internet?
0
Comment
Question by:pma111
1 Comment
 
LVL 13

Accepted Solution

by:
Daniel Helgenberger earned 500 total points
ID: 39611301
Using weak passwords in domain accounts does not pose a threat from the 'outside internet' by definition.
The same is true for 'weak' passwords. They do not pose a threat - but are of course much easier compromised.
A threat are only compromised accounts.

The problem is rather how many services use domain accounts (starting with LDAP binds) and how they are accessed from the outside.
Example:
Your organization uses Active Directory internally. There is a firewall which is blocking all AD traffic to the outside. There would be no thread. But this setup is rather ancient, since most organizations use some kind web based access nowadays.

You have to assess:
- Which services are accessible from outside the internet using domain based access? For instance this can include Exchange, VPN, Company Web, WLAN, LAN, ect.
- Then you need to assess how one compromised account could impact your organization

The range can be very wide. For instance, if you only have access to a company web side, the attacker can only view the resources there. If it is an Exchange account, the attacker can retrieve all kind of info about your organization, being OAB, confidential emails and as well using this account for spam mails; resulting in your mail server getting blacklisted by RBL's - which may have a huge impact on your business.

The most imminent threat poses a VPN access; which will grant the attacker access to all the resources the user account may access. If the compromised account is a domain admin, then you can start digging your grave.
The same is true for instance with WLAN when used with RADIUS. An attacker only needs to be in range of the WLAN.

This is the reason why domain accounts should be on a 'need to know' bases, eg. only have access to the resources they really need to have. And even if users do not like it, you need to impose a strong password policy. Further, run a script with deactivates domain accounts not being used for certain period.
Also, protect access to domain admin accounts. These should not be used for common users, not even an administrator should be in the 'domian admin' group but rather use a separate account with short term rotating password. Rotating passwords help a lot here, if maybe an old password is found or users cannot apply a 'same password everywhere' policy; compromising their domain password if a private account gets hacked.
Also, protect VPN and Terminal Services access with two-factor-verification; eg. a PKI or SmartCard on top the domain credentials. As a general method with these services you should employ every security measure possible updating security policies ASAP when new options become available.
0

Featured Post

Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

Join & Write a Comment

Resolve DNS query failed errors for Exchange
In this article, we will see the basic design consideration while designing a Multi-tenant web application in a simple manner. Though, many frameworks are available in the market to develop a multi - tenant application, but do they provide data, cod…
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…

707 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

Need Help in Real-Time?

Connect with top rated Experts

15 Experts available now in Live!

Get 1:1 Help Now