Вы находитесь на странице: 1из 161

FINDING COUNTERMEASURES FOR ACTIVE DIRECTORY THREATS

USING NIST 800-30 FRAMEWORKS






By
Aldo Elam Majiah
2-2012-206




A thesis submitted to the Faculty of

ENGINEERING & INFORMATION TECHNOLOGY




in partial fulfillment of the requirements
for the
MASTERS DEGREE
in

INFORMATION TECHNOLOGY












SWISS GERMAN UNIVERSITY
EduTown BSD City
Tangerang 15339
Indonesia




August 2014

Revision after the Thesis Defense on 25 August 2014
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 2 of 161





Aldo Elam Majiah


STATEMENT BY THE AUTHOR

I hereby declare that this submission is my own work and to the best of my
knowledge, contains no material previously published or written by another person,
nor material which to a substantial extent has been accepted for the award of any
other degree or diploma at any educational institution, except where due
acknowledgement is made in the thesis.

Aldo Elam Majiah
_______________________________________ ________________
Student Date

Approved by:


Dr. Ir. Mohammad A. Amin Soetomo, M.Sc.
________________________________________ __________________
Thesis Advisor Date


Charles Lim, M.Sc.
________________________________________ __________________
Thesis Co-Advisor Date


Dr. Ir. Gembong Baskoro M. Sc.
______________________________________ _________________
Dean Date
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 3 of 161





Aldo Elam Majiah


ABSTRACT

FINDING COUNTERMEASURES FOR ACTIVE DIRECTORY THREATS USING
NIST 800-30 FRAMEWORKS

By
Aldo Elam Majiah
Dr. Ir. Mohammad A. Amin Soetomo, M.Sc., Advisor
Charles Lim, M.Sc, Co-Advisor

SWISS GERMAN UNIVERISTY
Bumi Serpong Damai

Data showed that many Active Directory (AD) implementations in the enterprises /
organizations are insecure. Since AD is ubiquitous and it is an essential part of a
security enterprise, security of AD is imperative. This research focuses on how to
secure an AD environment. It uses a risk assessment approach to find threats in
existing AD and then recommend countermeasures for these threats. A new AD risk
assessment is developed for the purpose of this research. Components of AD, where
the risk assessment is performed, are also defined. The results of the assessment are a
series of countermeasures for AD and a set of security-based GPO, both to be
implemented in the assessed AD environment. To ensure the effectiveness,
implementable level, and evaluation of the risk assessment results, demonstration of
the countermeasures and experts judgment are also conducted. The research
concludes that risk assessment approach for securing an AD environment is highly
implementable for securing an organizations AD. Specific threats on an
organizations AD environment and the recommended countermeasures are identified
in well-structured processes, which can be performed in accordance to the developed
framework.

Keywords: Active Directory, Countermeasure, Threat, Risk, Framework
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 4 of 161





Aldo Elam Majiah













Copyright 2014
By Aldo Elam Majiah
All rights reserved
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 5 of 161





Aldo Elam Majiah


DEDICATION


I dedicate this thesis to my family; my wife Maya Patricia Siwy, my wonderful son
Castiel Elivair Majiah and his grandmother Haryati. Thank you for being my strength
throughout this entire master program.

I can do all this through him who gives me strength. (Philippians 4: 13).
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 6 of 161






Aldo Elam Majiah
ACKNOWLEDGMENTS

The author wishes to thank my advisors in Swiss German University, Dr. Ir.
Mohammad A. Amin Soetomo M.Sc. and Charles Lim, M.Sc, who were more than
generous with their expertise and precious time. Their guidance made the completion
of this research an enjoyable experience. Special thanks to Jusak Soehardja and his IT
team for letting me perform data collection in their organization.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 7 of 161




Aldo Elam Majiah

Table of Contents
STATEMENT BY THE AUTHOR ........................................................................................... 2
ABSTRACT ............................................................................................................................... 3
DEDICATION ........................................................................................................................... 4
ACKNOWLEDGMENTS ......................................................................................................... 6
CHAPTER 1 - INTRODUCTION ........................................................................................... 13
1.1 Background ............................................................................................................... 13
1.2 General Statement of Problem Area.......................................................................... 13
1.3 Research problem ...................................................................................................... 14
1.4 Research objectives ................................................................................................... 15
1.5 Research questions .................................................................................................... 15
1.6 Significance of study ................................................................................................. 16
1.7 Scope and limitation .................................................................................................. 16
1.8 Thesis structure ......................................................................................................... 17
CHAPTER 2 - LITERATURE REVIEW ................................................................................ 19
2.1 Active Directory ........................................................................................................ 19
2.1.1 Active Directory as a directory service .............................................................. 19
2.1.2 Active Directory fundamentals .......................................................................... 20
2.1.3 Charateristic of Active Directory ....................................................................... 21
2.1.4 Related works on AD and network security ...................................................... 24
2.2 Risk frameworks ....................................................................................................... 30
2.2.1 Octave Allegro ................................................................................................... 30
2.2.2 FAIR .................................................................................................................. 31
2.2.3 RISK IT .............................................................................................................. 31
2.2.4 NIST SP 800-30 ................................................................................................. 32
2.2.5 NIST SP 800-30 Revision 1 ............................................................................... 35
2.2.6 AD risk framework ............................................................................................ 36
2.3 Threat and countermeasure ....................................................................................... 38
2.4 Expert judgment ........................................................................................................ 42
2.5 Design science ........................................................................................................... 42
2.6 Theoretical framework .............................................................................................. 46

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 8 of 161




Aldo Elam Majiah

CHAPTER 3 - RESEARCH METHODOLOGY .................................................................... 48
3.1 Steps of research methodology ................................................................................. 49
3.2 Key activities for design and development ............................................................... 49
3.2.1 AD system characterization ............................................................................... 49
3.2.2 Threat sources and events identification ............................................................ 53
3.2.3 Identification of vulnerability ............................................................................ 53
3.2.4 Determination of likelihood of occurence ......................................................... 54
3.2.5 Determination of impact magnitude .................................................................. 55
3.2.6 Risk determination ............................................................................................. 55
3.2.7 Countermeasure recommendation ..................................................................... 56
CHAPTER 4 RISK ASESSMENT & ANALYSIS .............................................................. 57
4.1 Design and development (risk assessment) ............................................................... 57
4.1.1 AD system charaterization ................................................................................. 57
4.1.2 Threat sources and events identification ............................................................ 57
4.1.3 Identification of vulnerability ............................................................................ 59
4.1.4 Determination of risk level and countermeasure ............................................... 60
4.2 Demonstrate countermeasure (prototyping) .............................................................. 61
4.3 Evaluate (expert judgment) ....................................................................................... 77
4.4 Observation ............................................................................................................... 77
CHAPTER 5 CONCLUSION .............................................................................................. 85
5.1 Conclusion ................................................................................................................. 85
5.2 Future works .............................................................................................................. 86
GLOSSARY ............................................................................................................................ 87
REFERENCES ........................................................................................................................ 90
APPENDIX .............................................................................................................................. 94
Appendix 1: AD Characterization Assessment (original forms) ......................................... 94
Appendix 2: AD Characterization Assessment (printed) ................................................... 102
Appendix 3: List of Threat Events and Description ........................................................... 108
Appendix 4: Vulnerability Identification Table ................................................................. 133
Appendix 5: Threat Risk-Level and Its Countermeasures ................................................. 141
Appendix 6: Experts Profiles ............................................................................................ 150
Appendix 7: Artifacts Evaluated by Experts ...................................................................... 152
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 9 of 161




Aldo Elam Majiah

Appendix 8: Experts Opinion ........................................................................................... 158
CURRICULLUM VITAE ..................................................................................................... 161


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 10 of 161




Aldo Elam Majiah

List of Figures
Figure 1: Fishbone diagram of weak AD security ................................................................... 15
Figure 2: Typical AD domain diagram (Robbie Allen, 2003) ................................................. 20
Figure 3: AD forest example (Robbie Allen, 2003) ................................................................ 20
Figure 4: AD logical and physical structures (Sakari Kouti, 2004) ......................................... 21
Figure 5: Components of AD (Sakari Kouti, 2004) ................................................................. 21
Figure 6: Building blocks of AD (Sakari Kouti, 2004) ........................................................... 22
Figure 7: Building blocks of AD (Brian Desmond, 2013) ....................................................... 22
Figure 8: Elements of AD (Rommel, 2008)............................................................................. 22
Figure 9: Major components of AD (Kocis, 2001) .................................................................. 23
Figure 10: Components of AD (Wilkins, 2001) ...................................................................... 23
Figure 11: Summary of AD components ................................................................................. 24
Figure 12: Threat and countermeasure relationship (Chadwick, 2005) ................................... 26
Figure 13: Detailed AD threat & countermeasures (Chadwick, 2005) .................................... 27
Figure 14: Countermeasures derived from technical measures and policy (Sandberg, 2013) . 27
Figure 15: Countermeasures needed to secure enterprise endpoints (Sandberg, 2013) .......... 28
Figure 16: Octave Allegro steps (Richard A. Caralli, 2007) ................................................... 30
Figure 17: Fair methodology ................................................................................................... 31
Figure 18: Risk IT Process Model (ISACA, 2009).................................................................. 32
Figure 19: Risk assessment activities (NIST, 2002) ................................................................ 34
Figure 20: Risk assessment processes (NIST, 2012) ............................................................... 35
Figure 21: Risk assessment steps (NIST, 2012) ...................................................................... 36
Figure 22: AD risk assessment framework .............................................................................. 37
Figure 23: Countermeasures technologies for preventing threats (Michael A. Davis, 2010).. 38
Figure 24: Technology and general security practices as countermeasures (Michael A. Davis,
2010) ........................................................................................................................................ 38
Figure 25: Security countermeasures model (Straub, 1986) .................................................... 39
Figure 26: Security countermeasures model (D'Arcy, 2007)................................................... 39
Figure 27: Threat & its agents (International Telecommunication Union, 2003) ................... 40
Figure 28: Threats point of view (Farahmand, 2004) .............................................................. 40
Figure 29: Relationship between security components (Lenaghan, 2007) .............................. 41
Figure 30: Design-science activities ........................................................................................ 43
Figure 31: Design processes .................................................................................................... 43
Figure 32: Design cycle in relation to mental activities .......................................................... 44
Figure 33: DSRP Model (Ken Peffers, 2006) .......................................................................... 46
Figure 34: Methodology and theoretical framework ............................................................... 47
Figure 35: AD components revolves around risk assessment framework .............................. 47
Figure 36: Thesis methodology ............................................................................................... 48
Figure 37: Distribution of key activities .................................................................................. 50
Figure 38: Distribution of threat events ................................................................................... 59
Figure 39: Vulnerability scan results ....................................................................................... 59
Figure 40: Summary of penetration testing report ................................................................... 60
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 11 of 161




Aldo Elam Majiah

Figure 41: Risk assessment result ............................................................................................ 61
Figure 42: AD for prototyping ................................................................................................. 62
Figure 43: Access files using alternative OS ........................................................................... 63
Figure 44: Offline password cracking using Ophcrack ........................................................... 63
Figure 45: raising functional levels .......................................................................................... 64
Figure 46: Primary and secondary DC ..................................................................................... 64
Figure 47: Successfully transferred RID master role ............................................................... 65
Figure 48: Computer-based OU deployment ........................................................................... 65
Figure 49: Reduce number of domain admins ......................................................................... 66
Figure 50: Configure an account ability to logon from only one host ..................................... 67
Figure 51: Fail pass-the-hash attack ........................................................................................ 67
Figure 52: Deploying restricted group ..................................................................................... 68
Figure 53: Using run as for administrative tasks ..................................................................... 68
Figure 54: Weak password policy............................................................................................ 69
Figure 55: Stronger password policy ....................................................................................... 69
Figure 56: Weak account lockout policy ................................................................................. 70
Figure 57: Password cracking using Medusa........................................................................... 70
Figure 58: Stronger account lockout policy ............................................................................. 71
Figure 59: Testing account lockout policy............................................................................... 71
Figure 60: Backup AD using Windows Server backup ........................................................... 72
Figure 61: WSUS configuration GPO ..................................................................................... 73
Figure 62: Successful exploit using Metasploit ....................................................................... 73
Figure 63: Fail exploit attempt ................................................................................................. 74
Figure 64: Nessus scan result ................................................................................................... 74
Figure 65: Cain and Abel sniffing FTP credential ................................................................... 76
Figure 66: Final AD risk assessment framework ..................................................................... 78
Figure 67: Final AD components ............................................................................................. 78
Figure 68: Risk assessment results (moderate risk level and up) ............................................ 79
Figure 69: Implementation of high risk GPO countermeasures .............................................. 80
Figure 70: Implementation of medium risk GPO countermeasures (1) ................................... 80
Figure 71: Implementation of medium risk GPO countermeasures (2) ................................... 81
Figure 72: Implementation of medium risk GPO countermeasures (3) ................................... 81


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 12 of 161




Aldo Elam Majiah

List of Tables
Table 1: Penetration testing activities data (IT Security Firm X, 2013) .................................. 14
Table 2: Strength and weakness of several risk assessment frameworks ................................ 36
Table 3: Design-science guidelines (Alan R. Hevner, 2004) ................................................... 45
Table 4: Table for likelihood of event initiation or occurrence (NIST, 2012) ........................ 54
Table 5: Table for likelihood of threat event resulting in impact (NIST, 2012) ...................... 54
Table 6: Table for determining/assessing overall likelihood (NIST, 2012) ............................ 54
Table 7: Table for assessing impact of threat events (NIST, 2012)......................................... 55
Table 8: Table for determining level risk as combination of likelihood and impact (NIST,
2012) ........................................................................................................................................ 55
Table 9: Table for describing level of risk assessment (NIST, 2012) ..................................... 56
Table 10: Threat sources taxonomy (NIST, 2012) .................................................................. 58
Table 11: Final countermeasures and their categories ............................................................. 82


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 13 of 161




Aldo Elam Majiah

CHAPTER 1 - INTRODUCTION
1.1 Background
Active Directory (AD) is Microsofts implementation of centralized management of users,
hosts, and other objects (Microsoft, 2006). AD is a logical structure that can holds objects
such as users and hosts. The shape of an AD look like a tree of folders, with the root of it
represents the name of the domain.
The size of an AD is varied much; a single AD may consist of from a few to thousands of
hosts and users. Since it is not easy to manage a few hundreds to thousands of users and
hosts, Microsoft creates AD directory service tools to centrally manage users, accounts,
servers, group policies, and services. The tools also function as the central authority for
network security. By centrally managing servers, systems administrators are able to maintain
users, hosts, and policies from a single central location, simplifying the process of host and
user management. A centralized system such as this needs a top of the line security since a
compromised AD means compromising the whole hosts and users therein.
Active Directory (AD) is the core component of the Windows server infrastructure. A well
designed and implemented Active Directory is the foundation of any optimized Windows
infrastructure. A correctly designed, configured and implemented Active Directory will
significantly reduce this risk. More and more companies are realizing that a properly secure
Active Directory is a critical component of a fully secured Windows network (Barnard,
2006). Hence the security of the AD is one of the most important things to be managed by
any enterprises. Microsoft itself realizes that Active Directory environment often becomes a
target to rapidly growing and evolving external attack (Microsoft, 2013).

1.2 General Statement of Problem Area
AD is considered to be a critical part of a network infrastructure, moreover, its ability to
mitigate internal threats is also considered crucial for increasing overall internal security of
the network (Tankard, 2012). With such importance, any enterprise should have their AD
secured properly. The tasks of securing AD are not easy as the administrative management is
complex and time consuming. According to a survey (Osterman Research, 2010), 42%
organizations deploys users in incorrect security groups or distribution list when using group
policy management, a well-known feature of AD. The research also found that managing
groups in AD is a complicated task and is requiring time investment. Furthermore, another
survey (InformationWeek Analytics, 2011) states that the biggest challenge in maintaining
information and network security in an organization is management of complexity. All in all,
AD management can be very complex and time consuming. And if it is not done properly, it
could impact security or business performance (Tankard, 2012).
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 14 of 161




Aldo Elam Majiah

The following data from an IT security consulting firm showed that AD could be
compromised almost in every cases of internal penetration testing. Table below shows
penetration testing activities during year 2011 to 2013 from an IT security firm. Some of
these penetration testing activities include internal black box pen-testing. In almost all
internal black box pen-testing activities, AD of the enterprises were compromised. Name of
the companies involved in pen-test activities were not disclosed, instead we are using
company type and numerical representation to identify the companies.
Table 1: Penetration testing activities data (IT Security Firm X, 2013)
Company type Pen-test activities AD domain
level
How AD was compromised
Undisclosed data










These data were taken during year 2011 to 2013 from a security consulting firm in Jakarta
Indonesia. Although the data are small compared to the existing AD environment in the
whole region, it can serve as a basis of an argument that there are some apparent problems in
developing secure AD environment.

1.3 Research problem
Referring to penetration testing data from the company in the previous section, we can
deduce there are problems in implementing a secure AD. In almost all internal penetration
testing, save for one company, the enterprises AD is compromised. The method of
compromising AD is not always the same from company to company as stated in the last
column of the table.
Security risks can be reduced by taking action on three major components: people, process,
and technology (Janes, 2012). Taking these three accounts into AD security problem, the
author creates following fishbone diagram to identify root cause of the problem.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 15 of 161




Aldo Elam Majiah



Figure 1: Fishbone diagram of weak AD security

Three major domains; people, process, and technologies, are contributing to a weak AD
security. Each domain consists of several causes. People domain seems to contribute more
compared to other domains. This is aligned with the notions that people are the weakest link
in IT security and that IT security is only as secure as the weakest link (Michael T.
Simpsons, 2011).
Technology as the causes of weak AD is a very interesting domain to be explored. A better
understanding in technological management of AD may help a lot in securing AD. The focus
of this research is on technological domain. The reasons that this thesis is focusing on
technology part instead of people and process domain are because technology are more static
in nature compared to people and process domains. In focusing on technology domain to
secure AD, the author hopes solution of the problem of weak AD can be applied to wider and
diverse environment.
The rest of the thesis will emphasize on finding various threats and countermeasures in AD.
The author chooses two main areas which are interrelated as the main focus of this research:
existence of various threats and lack of knowledge countermeasures implementation.
1.4 Research objectives
The main objective of this research is to find known and existing threats in AD and finding
proper countermeasures for these threats. Countermeasures are defined as an action taken to
counteract a danger or threat (Oxford University Press, 2010).

1.5 Research questions
Deriving from the research objectives, the research questions for the thesis are:
What are existing threats for Active Directory?
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 16 of 161




Aldo Elam Majiah

How to countermeasure for these threats?
In order to answer the research question, we first have to describe known, if not all, threats to
AD. Next, we need to assess an AD to find actual threats in that particular environment.
Threats for AD may come from weakness in operating system, applications, databases,
policies, or other related security issues. We need first to list all these threats, assess the
actual threats in an AD environment, and then recommend solutions of how to counter them.
For the purpose of finding threats in an AD environment, this research utilizes risk
assessment approach.

1.6 Significance of study
The study is significant for two reasons.
First, this research will provide a risk assessment approach for identifying threats and
developing countermeasure for AD. Although risk assessment is a well-known approach,
implementing its methodology for assessing security of AD environment has not been done
before. The author hopes this methodology can be re-used by other organizations as a
preferred methodology for assessing their AD environment.
There are other methodologies and approaches for finding threats in applications, one of the
most used is using threat modeling as described in (Shostack, 2014). This approach is quite
useful in times of designing and building applications, as it is implementable in every step of
SDLC. This method is, in fact, the method used by Microsoft itself for securing many
applications. But threat modelling approach is mainly useful during development of
applications as this method dissects applications and then tries to find all possible threats in
every entry points to the applications. This threat modeling method, even though very
powerful in finding threats to applications, mostly deals with low level application behaviors
in contrast to holistic AD environment implementation point-of-view as used in this research.
In AD, we are dealing with a set of applications (for example DNS, LDAP, DHCP, Kerberos,
etc.) that have been packed together into one big application. And it is the implementation of
this one big application in a particular environment that should be assessed.
Second, the study will address the issue of weak security implementation of AD. This can
help enterprises to understand what is required to secure their AD and Windows environment.
Since AD and Windows-based environment are ubiquitous, this research will help securing
wide and various environment areas.

1.7 Scope and limitation
The scope of the thesis will be focused on threats caused by technological aspects. The author
recognizes threats can occur due to problems in people and process domains, for example
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 17 of 161




Aldo Elam Majiah

lack of the administrators security skill may lead to weak security configuration or the fact
that missing IT security policy may be the cause of overall weak security in managing IT
infrastructure. But these domains are wide and may fall out of the scope this thesis. The thesis
will focused on threats from technology domain point of view, the author leaves discussions
of threats on other domains to future works.
Threats are changing in daily basis and have a tendency of increasing over time. Hence the
threats, and their countermeasures, discussed in this research are an ever increasing list. As
the time of this writing, Windows operating system has reached a server version of 2012 and
client version of Windows 8.1. The newest threats and countermeasures from these newer
operating systems may not be available or well-studied yet. Likewise, older threats that are
present in older AD environment may not be present in newer systems. This fact gives a
notion that threats and countermeasure presented in this research are not a complete list; but it
is designed as a search process in which threats (and countermeasures) can be added or
subtracted over time.

1.8 Thesis structure
The structure of the thesis begins with chapter 1 which describes research background,
problem area, research objectives and research questions, significance of study, and the scope
and limitation of the research.
Chapter 2 developed literature review for building theories and frameworks to be used in this
thesis. Chapter 2.1 discusses AD in general and generates six components of AD that will be
used in risk assessment process later on. Chapter 2.2 discusses several risk frameworks. In
this subchapter, an AD risk framework is introduced. The rest of chapter 2 describes threat
and countermeasure relationships, a basis for expert judgment process, and literature review
for design science methodologies. The result of this chapter is a theoretical framework to be
used in this research. The framework shows how to perform risk assessment on AD in order
to find out threats and recommend related countermeasures.
Chapter 3 includes the research methodology used in the research, which is derived from
DSRP model, a design science methodology discussed in previous chapter. In addition, key
activities in performing risk assessment on AD are also defined in this chapter. More than
sixty key activities are elaborated in this chapter. This chapter also includes matrices and
definitions for performing risk assessment process, description on how to calculate and
estimate likelihood, impact, and risk level are detailed in this chapter.
Chapter 4 begins with the actual risk assessment process. It starts with system
characterization and ends with recommended countermeasures for that particular AD being
assessed. More than two hundreds threat events that are related directly or indirectly to AD
are stated. The author conducts data gathering about AD system characterization and related
vulnerabilities found in the AD using several methods such as; interview with the
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 18 of 161




Aldo Elam Majiah

organization, penetration testing in the organizations network, and vulnerability assessment.
All data from these activities are added to as input for vulnerability identification process.
Next, a series of risk assessment process such as determining likelihood, impact, and risk
level are performed. Countermeasures are then created and recommended against threat that
has risk level more than moderate (that is moderate, high, and very high). Risks level lower
than a low criterion was accepted. It is also worth noted that the risk assessment results were
based on the risk appetite and culture of an organization, and for this research it is assumed
that risk appetite and culture of the organization was integrated into the assessment.
In chapter 4, several countermeasures are also demonstrated to see if they are implementable
and effective against the threats in the prototyping phase. The prototyping is performed using
exact replica of AD being assessed but it is performed in a virtual environment, not in the real
production AD environment of the organization. The result of the prototyping phase is tested
countermeasures. Expert judgment was also conducted to evaluate AD risk assessment
frameworks, AD components, security GPO, and threatcountermeasure pairs. Security GPO
and threat-countermeasure pairs are the result from risk assessment process.

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 19 of 161




Aldo Elam Majiah

CHAPTER 2 - LITERATURE REVIEW
2.1 Active Directory
2.1.1 Active Directory as a directory service
Active Directory is Microsofts implementation of directory service. Directory service
provides the means to hierarchically organize and manage information (Beth Sheresh, 2002).
It also provides a way to securely manage complex systems of interrelated information.
Several directory services are known, for example: X.500, LDAP, DNS, OpenLDAP, IBM
SecureWay, Sun iPlanet, eDirectory, and Active Directory. Active Directory will become the
focus of this thesis.
(Timothy A. Howes, 2003) divides directory service into the following categories:
Application-specific directories. Examples in this category include the IBM/Lotus
Notes, Microsoft Exchange directory, and sendmail message transfer agent (MTA).
Network operating system (NOS)based directories. Examples in this category
include directories such as Novell's eDirectory, Microsoft's AD, Sun Microsystems' NIS,
and Banyan's StreetTalk directory.
Purpose-specific directories. These are directory services are specifically designed for a
purpose and are not extensible, for example: DNS and Switchboard directory.
General-purpose, standards-based directories. These are directories developed to
serve the needs of applications; for example LDAP and X.500-based directories.
There is also other kind of directory service; for example as the one shown in the research of
(Ihor Kuz, 2002). He proposes a wide-area management system using a directory service
which implements LDAP and DNS as the backbone of the system. Although still in the
research stage and some protocols have not yet been defined, this directory service is more
advanced as it integrates architecture for location-based worldwide resource management.
According to (Beth Sheresh, 2002), AD is one of technologically inventive network directory
service implementations. AD integrates Microsofts key directory service and network
technologies, such as LDAP and DNS. She also mentions that AD has four models:
Data model; AD is an information data store containing objects that represent network
resources, users, and a wide range of information.
Security model; AD is a Windows security infrastructure which uses ACL to protect
directory objects. It also employs multiple security technologies, such as using Kerberos
for authentication, SSL/PCT for encryption, and SAM for authentication with OS level.
Administration model; AD allows authorization of users to perform sets of actions on
objects or attributes within an OU. AD also provides delegation over directory tasks
Replication model; AD is comprised of replica system; this means changes made at any
replica are propagated to all directory information, and all replicas are consistent.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 20 of 161




Aldo Elam Majiah

2.1.2 Active Directory fundamentals
Data is stored within Active Directory in a hierarchical fashion similar to the way data is
stored in a file system (Robbie Allen, 2003). Each entry is referred to as an object and there
are two types of objects: containers and non-containers. The most common type of container
you will create in Active Directory is an Organizational Unit. AD domain diagram below
shows company domain mycorp.com has two OU called finance and sales. Sales OU has two
more OUs inside it, named Pre-sales and Post-Sales. And inside Pre-Sales OU there are
object such users, computers, and groups.

Figure 2: Typical AD domain diagram (Robbie Allen, 2003)

A domain can exist in a complex domain tree, called forest. This forest may consist of several
domains. Each of this domain can have hundreds or even thousands objects within it.

Figure 3: AD forest example (Robbie Allen, 2003)
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 21 of 161




Aldo Elam Majiah

2.1.3 Charateristic of Active Directory
AD can also be viewed as having two, mostly independent, structures; logical and physical
(Sakari Kouti, 2004). The representation of domain diagram in figure 4 below is a physical
and logical view point of AD. The physical part consists of sites, replication, replicas,
partitions, domain controllers, and global catalog. The logical part consists of administrative
policy boundary, security policy boundary, and DNS namespace.

Figure 4: AD logical and physical structures (Sakari Kouti, 2004)


Figure 5: Components of AD (Sakari Kouti, 2004)

In addition (Sakari Kouti, 2004) also introduced the building block of AD as follows:
Domain Controllers, Domain, trust relationship, OU and other objects (user, computer, and
shared folder), groups, sites, replication, and global catalog. Furthermore, he also stated that
AD had a database of information which was represented as objects. These objects could be
in the form of user, group, computer, contact people, printers, shared folders, application
services, other resources, or configuration information.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 22 of 161




Aldo Elam Majiah


Figure 6: Building blocks of AD (Sakari Kouti, 2004)

(Brian Desmond, 2013) describes the building blocks of AD were as follows: domain and
domain trees, forests, OU, global catalog, FSMO roles, domain and forest functional level,
and groups.

Figure 7: Building blocks of AD (Brian Desmond, 2013)

Similar to (Brian Desmond, 2013) and (Sakari Kouti, 2004), (Rommel, 2008) suggested the
following as the elements of AD: forest, domain tree, OU and leaf objects (such as computer
and user accounts), sites, and GPO.

Figure 8: Elements of AD (Rommel, 2008)

(Kocis, 2001) in his book listed major components of AD as follows: namespace, domain
tree, forest, domain, OU, and site. (Wilkins, 2001) described that AD could be viewed as
logical or physical components; the logical view was for the design aspect and the physical
view was the network components where Active Directory was executed. The logical
components included domains, trusts, trees, forests, containers, and organizational units. The
physical components included Domain controllers, subnets, and sites.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 23 of 161




Aldo Elam Majiah



Figure 9: Major components of AD (Kocis, 2001)


Figure 10: Components of AD (Wilkins, 2001)

Diagram in figure shows the summary of all components of AD. The components are divided
into logical and physical. The logical components consist of DNS, forest design domain and
domain trees, trust relationship, groups, OU & leaf objects, administrative & security
boundary, FSMO roles, domain & forest functional level, and GPO. The physical
components consist of sites, subnets, DC, replication, global catalog & replicas.

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 24 of 161




Aldo Elam Majiah


Figure 11: Summary of AD components

For the purpose of this research, several components are re-grouped, resulting in six
components of AD. The groupings into six components are meant to ease in finding threats
which will be used later in risk assessment processes. These components are:
1. AD design and boundary; which consist of forest design, domain & domain & domain
trees, trust relationship.
2. AD management: groups, OU & leaf objects, administrative & security boundary,
FSMO roles, domain & forest functional level.
3. Policy implementation which is related to GPO implementation in AD.
4. Security of AD computer members.
5. Security of network.
6. Security of DC.

2.1.4 Related works on AD and network security
Microsoft, as the creator of AD, uses four interrelated strategies to protect AD (Microsoft,
2013). These four strategies are: identifying vulnerabilities, reducing AD attack surface,
monitoring signs of compromise, and developing long-term security plan. Each strategy can
be detailed into several security processes as follows:
1. Identifying vulnerabilities:
Protect and update software
Fix faulty configuration, for example by:
Securing privileged accounts and groups.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 25 of 161




Aldo Elam Majiah

Avoiding disabled security features on users workstations.
Avoiding granting excessive rights and permissions (for example to service
accounts).
Avoiding the use of identical local credentials across systems.
Avoiding installation of unauthorized applications and utilities.
Eliminating and controlling membership in highly privileged groups.
Eliminating unnecessary applications, Internet contents, and freeware on DC.
2. Reducing AD attack surface:
Managing privileged accounts and security groups.
Leveraging security built-in features.
Utilizing threat reducing tactics, such as: ensuring DC physical security, securing
admin workstations, using access control.
3. Monitoring for signs of compromise:
Implementing audit policies and detailing objects and systems to audit.
Monitoring events to help detecting compromise attempts.
4. Developing a long-term security plan:
Identifying, segregating, and securing critical users, applications, and systems.
Replacing legacy applications and systems with newer solutions.
Developing comprehensive protection strategies, such as:
Isolating legacy systems and applications.
Implementing controls that can be easily followed by users.
Utilizing security best practices for AD.
Ensuring applications and OS are up to date by implementing a patch
management.

Microsoft states for creating a secure AD, four strategies are needed: identifying
vulnerabilities, reducing AD attack surface, monitoring signs of compromise, and developing
long-term security plan. These strategies are in fact best practices and countermeasures for
securing AD.
Next research related to AD was conducted by researchers from University of Salford,
England. The research analyses threats in AD using STRIDE classification methodology
(Chadwick, 2005). The research limits its scope to AD that also holds roles as Web server
and has no trust to other domains.
Since it is based on Microsofts STRIDE framework, the research concludes that each threat
category in the framework also exists in AD. Those threats are: spoofing, tampering,
repudiation, information disclosure, denial of service, and elevation of privilege. The paper
also describes common countermeasures for each threat. Unfortunately, the paper does not
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 26 of 161




Aldo Elam Majiah

describe any real example of the threats. There is not any example of how to perform, for
example, a denial of service. The paper does not disclose how the attack could be performed,
or tools needed to do it. It is a theoretical paper discussing theoretical threats. In his paper,
(Chadwick, 2005) created suggested countermeasures come from knowing the threats. Each
threat can be countered by applying several countermeasures, and same countermeasure can
be applied to thwart several threats as shown in figure 12.


Figure 12: Threat and countermeasure relationship (Chadwick, 2005)

Another disadvantage of this research is that the framework used (STRIDE) provides a broad
categorization of the threats. For example let us take a look at denial of service threat; one
can ask the following questions relating to this threat: which service is to be denied? Which
vulnerability involved in the DoS? Etc. There could be many types of DoS threats in an AD,
is the countermeasure good enough to handle all of these DoS threats? This signifies that it is
not enough to treat threats as major categorization as shown by STRIDE. It is certainly
helpful to have a detail explanation of the threat.
Figure 13 shows the contribution of this papers research. Red boxes are threats and green
boxes are countermeasures. The arrows in the figures are all one way arrows, pointing from
threats to countermeasures. It indicates which threats can be mitigated with which
countermeasures. A threat may have more than one arrow, indicating a threat may need
several countermeasures.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 27 of 161




Aldo Elam Majiah


Figure 13: Detailed AD threat & countermeasures (Chadwick, 2005)

(Sandberg, 2013)s research was related to security of endpoint in the enterprise. The
conclusion of this thesis states that there are protecting enterprise endpoints needs a
combination of technical measures and policy.

Figure 14: Countermeasures derived from technical measures and policy (Sandberg, 2013)

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 28 of 161




Aldo Elam Majiah

There are four minimal set of technical measurement for securing enterprises endpoint:
inventory of hardware and software, patch management, security configuration management,
and mobile device management. However, to build a good security several additional
measures are needed, such as: better mobile device management, an anti-virus product,
service for helping users with new endpoints, and software whitelisting tool.
A good security policy is also needed to secure enterprise endpoints. The policy should
include: motivation for securing endpoints, technical measures employed, affected users
privacy, expectations from the users, and pointers to other documentations.

Figure 15: Countermeasures needed to secure enterprise endpoints (Sandberg, 2013)

Research from (Bertino Bruschi, 2005) discusses existence of threat in Microsoft SQL server,
a server commonly found in Windows infrastructure. It focuses on security threats that can
arise against an SQL server when included in Web application environments. The paper
identifies three entry point of attack for SQL server: as web application (client side), network,
and SQL server port. Another research from (Eichstdt, 2005) which is still related to threats
in Windows environment, presents threat model attack points structured in accordance to web
services architecture. It states several attacks points for this particular type of server: external
attacker, web service, ASP net gate, internal attacker, unmanaged code, and application. The
two research shows there are many attack points on Windows related infrastructures.
Several researches describe the importance of attack chaining in the network. (Ammann,
2000) addresses vulnerabilities due to the configuration of various hosts in a network. They
then create a modeling approach to be used to analyze overall security of a network based.
The model is based on the interactions of vulnerabilities within a single host and within a
network of hosts, hence introduced chained exploitation. A research paper from (Hale, 2004)
presents a framework for chained exploitation attack analysis; the framework is comprised of
modeling for network elements, system vulnerabilities and attacker capabilities. The research
Technical measure
inventory of hardware and software
patch management
security configuration management
mobile device management
anti-virus
service for new users
software whitelisting tool
Policy
motivation for securing endpoints
technical measures employed
affected users' privacy
users' expectations
pointers to other documentations
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 29 of 161




Aldo Elam Majiah

integrates the framework into iterative process supporting automated vulnerability analysis by
enumerating vulnerability interactions and then presents it in a chaining tree presentation.
(Paul Ammann, 2005)s research is somewhat more advanced from Hales. He provides an
alternative approach to (Hale, 2004) research by utilizing maximal level of penetration
possible on a host. Paul argues that chaining tree presentation often becomes unmanageable
because they are exponentially growing as the size of the network grows. Instead, it is better
to look for specific degrees of compromise on host, and focusing on that level of
compromise.
Other researches show how to countermeasure network related threats. (Asha. N, 2012)
studies different forms of SQL injection and proposes countermeasures for SQL injection
attack that is independent of platform and database. (Manadhata, 2011) introduces the use of
attack surface measurement as an indicator of the systems security. They argue that the
smaller the attack surface, the more secure the system. And for Windows related
infrastructure, there are three methods of determining the attack surface: determining
Windows attack vectors (for example: features, services, ports, and dynamic web pages),
assigning weights to reflect their attack enablement, and estimating weighted counts of the
attack vectors.
Still related to securing a system, NIST publish a standard that can be used to secure servers
(NIST, 2008). The standard describes in details on how to secure servers operating system,
secure software or application installed in the server, and maintain secure configuration (for
example through patches and upgrades, backup, or server monitoring). Australias Defence
Signal Directorate even publishes a standard for mitigating cyber intrusion for Microsoft
Windows servers (The Defence Signals Directorate Australia, 2012). The standard defines
top mitigations for Microsoft servers as: application whitelisting, patch and deploy current
OS and applications, and restrict administrative privileges.
Availability as a security component is also discussed several papers. One of them is (Huang,
2004), which strengthens security using hardware redundancy in an implementation of DNS.
The concept of the paper is creating two integrated clusters of DNS servers that constantly
rotates individual servers role, handles failures of one server gracefully, and confines the
damages of successful intrusion to a limited time. Hence increasing availability as well as
mitigating attacks in the same time. Another paper from (Yih Huang, 2006) defines similar
concept for mitigating attack on Windows servers, that is by periodically cleansed the server
into a known clean state. Although the concept of increasing availability and mitigating
attack in the same time are viable, it is not compatible yet with all types of computing
systems.

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 30 of 161




Aldo Elam Majiah

2.2 Risk frameworks
In this research, the author uses risk assessment approach to determine threat and
countermeasure in AD. The following are several risk assessment frameworks evaluated for
the purpose of finding a suitable mixture of risk assessment framework for evaluating AD.
2.2.1 Octave Allegro
OCTAVE is a collection of tools, techniques, and methods for risk based information security
assessments. This framework was developed by the Software Engineering Institute (SEI) of
Carnegie Mellon through its CERT program. OCTAVE came in several flavors; OCTAVE,
OCTAVE-S, and OCTAVE Allegro. OCTAVE Allegro is a methodology to streamline and
optimize the process of assessing information security risks so that an organization can obtain
sufficient results with a small investment in time, people, and other limited resources
(Richard A. Caralli, 2007).
Octave Allegro has the following steps of methodology:
1. Establish Risk Measurement Criteria. It is a process to establish the organizational
drivers that will be used to evaluate the effects of a risk to an organizations mission
and business objectives.
2. Develop an Information Asset Profile. This is the process of creating a profile for on the
information assets of the organization.
3. Identify Information Asset Containers which describe the places where information
assets are stored, transported, and processed.
4. Identify Areas of Concern. This is a risk identification process by brainstorming about
possible conditions or situations that can threaten an organizations information asset.
5. Identify Threat Scenarios; examining a broad range of additional threats.
6. Identify Risks: capturing various consequences of risk.
7. Analyze Risks: computing a simple quantitative measure of the extent to which the
organization is impacted by a threat.
8. Select Mitigation Approach; determining which of the identified risks require
mitigation and develop a mitigation strategy for those risks.

Figure 16: Octave Allegro steps (Richard A. Caralli, 2007)
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 31 of 161




Aldo Elam Majiah

2.2.2 FAIR
FAIR is a risk methodology which uses a taxonomy for breaking risk into sub-components
and then calculating an overall loss exposure profile based on calibrated data inputs. FAIR is
more of a high-level framework and is more conceptual when compared with the OCTAVE-
Allegro framework (Mark RM Talabis, 2013).
There are four FAIR stages:
1. Identify scenario components, which consist of two activities: identifying scenario
components and identifying the threat community.
2. Evaluate loss event frequency, which consist of five activities.
3. Evaluate probable loss magnitude, which consist of two activities; estimating worse
case scenarios and estimate probable loss magnitude.
4. Derive and articulate risk, plotting the loss event frequency and the probable loss
magnitude.

Figure 17: Fair methodology

2.2.3 RISK IT
Risk IT is a risk framework developed by ISACA, a leading global provider of knowledge,
community, advocacy, certifications and education on information systems security
assurance, IT-related risk compliance, and IT enterprise governance.
The Risk IT Framework describes a detailed process model for the management of IT-related
risk. In this model, multiple references are made to risk analysis, risk profile, responsibilities,
key risk indicators and many other risk-related terms (ISACA, 2009).



Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 32 of 161




Aldo Elam Majiah

The model of Risk IT is very detailed, it comprises of three models of risk evolving around
business objectives. The model consists of:
1. Risk governance: it is the process of ensuring that risk management practices are
embedded in the enterprise, enabling the enterprise to secure optimal risk-adjusted
return.
2. Risk evaluation: ensuring that IT-related risks and opportunities are identified, analysed
and presented in business terms.
3. Risk response: a process of ensuring that IT-related risk issues, opportunities are
addressed in line with business priorities and in a cost-effective manner.

Figure 18: Risk IT Process Model (ISACA, 2009)

For the risk evaluation part, ISACA defines the following activities:
1. Collect data: this is an activity to establish a model for data collection, collect data on
risk events, and identify risk factors.
2. Analyze risk: defining IT risk analysis scope and estimating IT risk, identifying risk
response options, and then performing a peer review of IT risk.
3. Maintain risk profile: map IT resources to business processes, determine business
criticallity of IT resources, understand IT capabilities, update IT risk scenario
components, maintain IT risk register and IT risk map, and develop IT risk indicators

2.2.4 NIST SP 800-30
NIST SP 800-30 defines risk management into three processes: risk assessment, risk
mitigation, and evaluation and assessment (NIST, 2002). For the risk assessment
methodology, NIST divided the assessment into 9 activities:
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 33 of 161




Aldo Elam Majiah

1. System Characterization. Identifying the boundaries of the IT system, along with the
resources and the information that constitute the system. Data gathering techniques that
can be used for this activity are: questionnaire, on-site interviews, document review,
and use of automated vulnerability scanning tools. Vulnerability scan includes a
mapping of the network and systems, identification of the services, and the creation of a
catalogue of vulnerable systems (Konstantinos Xynos, 2010). It is different than
penetration testing which has additional steps such as the exploitation of vulnerabilities
to confirm existence and determine damage if the vulnerability is exploited.
2. Threat Identification. Identifying the potential for a particular threat-source to
successfully exercise a particular vulnerability.
3. Vulnerability Identification. Analysing vulnerabilities related with the system
environment.
4. Control Analysis. Analysing implemented controls or controls that are planned for
implementation to minimize or eliminate the likelihood of a threat.
5. Likelihood Determination. Deriving an overall likelihood value indicating the
probability of a vulnerability may be exercised within the threat environment.
6. Impact Analysis. Measuring level of risk is to determine the adverse impact resulting
from a successful threat exercise of a vulnerability.
7. Risk Determination. Assessing the level of risk to the IT system.
8. Control Recommendations. Identifying and providing controls that could mitigate or
eliminate the identified risks.
9. Results Documentation. Documenting the result in an official report or briefing.

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 34 of 161




Aldo Elam Majiah


Figure 19: Risk assessment activities (NIST, 2002)

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 35 of 161




Aldo Elam Majiah

2.2.5 NIST SP 800-30 Revision 1
Revision 1 of NIST SP 800-30 (NIST, 2012) defines risk management processes as four
steps. Risk assessment is part of this processes. The risk management processes are: framing
risk, assessing risk, responding to risk, and monitoring risk. The diagram of the processes are
shown in the following figure 20:

Figure 20: Risk assessment processes (NIST, 2012)

The standards defines the risk assessment processes into four steps, prepare for the
assessment, conduct the assessment, communicate assessment results, maintain the
assessment. What we are interested most is the steps of conducting risk assessment, (NIST,
2012) defines five steps in conducting risk assessment. Depending on the purpose of the risk
assessment, organizations may find reordering these tasks advantageous.
1. Identify threat sources and events produced by those sources.
2. Identify vulnerabilities within organizations that could be exploited by threat sources
through specific threat events and conditions that could affect successful exploitation.
3. Determine the likelihood of how threat sources would initiate threat events and the
likelihood that these threats would be successful.
4. Determine the impacts from the exploitation of vulnerabilities by threat sources.
5. Determine risks as a combination of likelihood of threat exploitation and the impact of
such exploitation.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 36 of 161




Aldo Elam Majiah


Figure 21: Risk assessment steps (NIST, 2012)

2.2.6 AD risk framework
The following is strength and weakness of each discussed framework, presented in table 2.
Table 2: Strength and weakness of several risk assessment frameworks
Framework name Strength Weakness
Octave Allegro This framework provides details worksheets
(for example worksheet for impact criteria)
and questionnaires.

Compare to other framework, Octave Allegro is
very complex. The threat catalogs for this
framework are not provided. In contrast, NIST
800-30 SP1 has a very detailed threat catalogs.
FAIR Suitable for organizations that already have
established metrics in determining likelihood
or impact.
FAIR uses terminologies, approaches, and
matrices that are not aligned with other
frameworks. It may take some time to adjust to
FAIR framework. This framework is also difficult
to implement in organizations that does not
have prior risk assessment.
RISK IT The framework viewed risk assessment as a
cycling process to be implemented in an
organization. Well suited for a mature
organization.
Implementation processes need a significant
amount or resources that span the entire
organization. This framework cannot be
completed in a short time due to its complexity.
NIST 800-30 This framework is open-ended and can be
interpreted with a lot of flexibility by risk
assessors. Furthermore, input and output for
each activity are defined clearly.
Matrices provided in the example are high level
and subjective. Implementation examples
(worksheet, questionnaires) are not provided
with a lot of details.
NIST 800-30 Revision 1 This framework is suitable for assessing
technology related risks. As revision for NIST
800-30, this framework provides a lot of
details (worksheet, threat catalogs,
calculation of impact or likelihood) compare
to its predecessor.
The methodologies for conducting risk
assessment are now streamlined compare to
NIST 800-30. Process such as characterizing the
system to be assessed and recommending
countermeasures are not integrated into risk
assessment but part of other processes. System
characterization is now part of risk preparation
and countermeasure recommendation is part of
maintaining risk.

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 37 of 161




Aldo Elam Majiah

NIST 800-30 and its revision 1 counterpart are known to be very well suited to be used in
assessing a system. NIST 800-30 framework is very popular and heavily adopted not only by
federal agencies but also local government. The framework is also useful to be used in a
highly diverse environment such as AD. Moreover, inputs and outputs for each of the steps
are clearly identified. (Mark RM Talabis, 2013). For those reasons, the author chooses to
implement a hybrid risk assessment approach for assessing AD. The risk assessment
framework is taken from NIST 800-30 Rev.1 and NIST 800-30.
To better understand AD system, the author takes the first step of risk assessment process
from NIST 800-30, AD system characterization, and places it as the first step. Risk
assessment framework steps from NIST 800-30 Rev. 1 are taken completely as subsequent
steps. As shown in figure 21, these steps are identifying threat sources and events, identifying
vulnerabilities, determining likelihood, determining impact, and determining risk. Last, the
author comes back to take a step from NIST 800-30, control recommendation, and places it
as the last step of the risk assessment framework. This last step is necessary to answer for one
the research questions. Hence for this research, the following AD risk assessment framework
is used (as shown in figure 22):
1. AD system characterization.
2. Threat sources and events identification.
3. Identification of vulnerability.
4. Determination of likelihood of occurrence.
5. Determination of impact magnitude.
6. Risk determination.
7. Countermeasure recommendation.

Figure 22: AD risk assessment framework

The framework is derived from NIST 800-30 and NIST 800-30 revision 1 as these two
related frameworks are suitable for technology/system related risk assessment such as AD.
Step two (threat sources and events identification) to six (risk determination) follows steps
from NIST 800-30 revision 1. The first step (AD system characterization) and the last step
(countermeasure recommendation) are added from NIST 800-30. Activities 2 to 6 which are
AD system
characterization
Threat sources
and events
identification
Identification of
vulnerability
Determination of
likelihood of
occurrence
Determination of
impact magnitude
Risk determination
Countermeasure
recommendation
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 38 of 161




Aldo Elam Majiah

taken from NIST 800-30 revision 1 are quite detailed but not enough for performing risk
assessment because it misses prior and subsequent process. Following NIST 800-30 Revision
1 completely is also not a good option since it can prove overwhelming due to complexity of
the tasks at hand. For this reason, the author borrows prior process (system characterization)
and subsequent process (countermeasure recommendation) from NIST 800-30, thus creating
a complete yet simplistic, risk assessment framework suitable for assessing AD.

2.3 Threat and countermeasure
In his book (Michael A. Davis, 2010) states there are several technologies for preventing
threats. These technologies are: antivirus, host protection system that includes personal
firewall and pop-up blockers, host-based intrusion prevention (both behavioral or signature
based), rootkit detection, and general security practices (end-user education, defense in depth,
system hardening, automatic updates, and have security in-mind from the beginning).

Figure 23: Countermeasures technologies for preventing threats (Michael A. Davis, 2010)

In essence (Michael A. Davis, 2010) states for preventing threats, one need to apply both
technological countermeasures and general security practices. The countermeasures will then
be able to prevent known threats.

Figure 24: Technology and general security practices as countermeasures (Michael A. Davis,
2010)
Antivirus
personal firewall and pop-up blockers Host protection system
signature-based or behavioural-based Host-based intrusion prevention
Rootkit detection
end-user education, defense in depth, system hardening,
automatic updates, security in-mind
General security practices
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 39 of 161




Aldo Elam Majiah

Straub defines security countermeasures consist of deterrent and preventative controls
(Straub, 1990). Deterrents include passive and active controls. Example of passive controls
are security policy, and security awareness programs, or other information designed to deter
mischief attempts by providing information regarding correct / incorrect usage of information
systems and punishment for incorrect usage. Examples of active deterrents are audits of IT
assets, and monitoring of employee activities. The primary purpose of both active and passive
deterrents is to discourage potential offenders by the threat of getting caught and punished for
any violation.
Likewise, Straub states that preventative controls are security measures designed to prevent
any attempted IT violation and digital crime by blocking access to the information system or
inhibiting use of certain information system functions (Straub, 1986). Examples of
preventative controls are applications that employ access control methods such as passwords.

Figure 25: Security countermeasures model (Straub, 1986)

DArcy, on the other hand, conceptualizes security countermeasures as security policies,
security awareness programs, monitoring practices, and preventative security software
(D'Arcy, 2007). His model is derived on the basis that individuals are not fully aware of the
existence of these security countermeasures within their organizations.

Figure 26: Security countermeasures model (D'Arcy, 2007)
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 40 of 161




Aldo Elam Majiah

According to (International Telecommunication Union, 2003), a threat is a potential violation
of security, and it can be active or passive. Impersonating an authorized entity is an example
of active threats and eavesdropping to steal a clear password is an example of a passive
threat. Threats have agents; these agents are people or organizations that are able to use the
threats: hackers, terrorists, vandals, organized crime, state sponsored, or insiders of an
organization.

Figure 27: Threat & its agents (International Telecommunication Union, 2003)

According to a survey in 2006 (L. A. Gordon, 2006), four top categories of threats that
accounted for nearly 74.3% of the total losses were: viruses, unauthorised access, laptop or
mobile hardware theft, and theft of proprietary information.
A thesis dissertation from (Farahmand, 2004) describes that threats can be seen from two
points of view: threat agents and penetration techniques. From threat agent point of view,
threat can be manifested by: environmental factors, authorized users, and unauthorized users.
While from penetration techniques point of view, threats are caused by: physical, personnel,
hardware, software, and procedural.

Figure 28: Threats point of view (Farahmand, 2004)

Threats
Active
Passive
Threat agents:
hackers
terrorists
vandals
organized crime
state sponsored
insiders of an organization
two threats points of view:
threat agents
environme
ntal
factors
authorized
unautihori
zed
penetration techniques
physical personnel hardware software procedural
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 41 of 161




Aldo Elam Majiah

There are several works defining relationship between threats and countermeasures. One of
them is the work from Onwubiko et al. (Lenaghan, 2007), they represent the relationship
between threats, countermeasures, and other security components as shown in the following
figure.

Figure 29: Relationship between security components (Lenaghan, 2007)

As seen in the figure 29, countermeasures are for mitigating threats, vulnerabilities, and risks.
And it is up to the owner of the system to impose countermeasures.
(Lenaghan, 2007) defines relationship between threat, countermeasures, and other
parameters. Threat agents give rise to threats, threats exploit vulnerabilities, and the
existences of countermeasures are to mitigate both threats and vulnerabilities.
Another relationship between threats, vulnerabilities, and countermeasures are defined by
Common Criteria. According to Common Criteria, it is assumed threat agents will actively
seek to exploit opportunities to violate security policies both for illicit gains and for well
intentioned, but nonetheless insecure actions. Threat agents may also accidentally trigger
security vulnerabilities, causing harm to the organisation (Common Criteria for Information
Technology Security Evaluation, 2012). Vulnerabilities should be: eliminated, minimized, or
monitored.
Common Criteria also states that threats to security and organisational security policy
commitments should be clearly articulated and the proposed security countermeasures be
demonstrably sufficient. Security countermeasures should be adopted that reduce: the
likelihood of vulnerabilities, the ability to exercise (i.e. intentionally exploit or
unintentionally trigger) a vulnerability, and the extent of the damage that could occur from a
vulnerability being exercised.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 42 of 161




Aldo Elam Majiah

2.4 Expert judgment
Expert judgment is the use of structured and unstructured inputs from different individuals
who have specialist knowledge of a particular domain. This method of evaluation is used in
various fields such as problem structuring, model bounding, model structuring, and model
quantification.
This method relies on experts for evaluation. This brings up question the definition of expert.
According to Meyer and Broker, expert is a person who has a background in the subject
matter at the desired level of detail and who is recognised by his/her peers or those
conducting the study as being qualified to solve the questions (Mary A. Meyer, 2001). Ferrel
defines expert as a person with substantive knowledge about the events whose uncertainty is
to be addressed (Ferrell, 1994). OHagan states a simple conception is that an expert is
someone who has great knowledge of the subject matter. However, expertise also involves
how the person organises and uses that knowledge (OHagan, 2006).
Most studies in IT stream had to explicitly or implicitly rely on domain experts to evaluate
similarities or differences among various technologies (Chia-jung Tsui, 2010). The same
paper also describes several drawbacks of using expert validation techniques; it states that
although experts may be skillful in detecting the subtleties within and across the different
types of technologies, expert evaluation is often:
(1) Biased towards the views of specific experts contributing to specific studies,
(2) Static in the time of such evaluations, and
(3) Difficult to scale up to examine the relationships among a large number of ITs.

2.5 Design science
The methodology for this research will be taken from design science research point of view.
This subchapter deals with the basic of design science and the reason for selecting DSRP as
the methodology for this thesis.
(Salvatore T. March, 1995) defined there are two kinds of scientific interest in IT, descriptive
and prescriptive. Descriptive research aims at understanding the nature of IT. It is a
knowledge-producing activity corresponding to natural science. Prescriptive research aims at
improving IT performance. It is a knowledge-using activity corresponding to design science.
Hence March defined two kinds of science; natural science and design science. Natural
science is concerned with explaining how and why things are. Design science is concerned
with "devising artifacts to attain goals". Natural science explanations of how or why an
artifact works may lag years behind the application of the artifact. In medicine, for example,
the explanation of why a drug is effective in combating a disease may not be known until
long after the drug is in common use.
Still according to (Salvatore T. March, 1995), design science products are of four types,
constructs, models, methods, and implementations. And also, rather than posing theories,
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 43 of 161




Aldo Elam Majiah

design scientists strive to create models, methods, and implementations that are innovative
and valuable.
Design science consists of two basic activities, build and evaluate (Salvatore T. March,
1995). Building is the process of constructing an artifact for a specific purpose; build also
refers to the construction of the artifact, demonstrating that such an artifact can be
constructed. Evaluation is the process of determining how well the artifact performs and
refers to the development of criteria and the assessment of artifact performance against those
criteria. The constructed artifact itself presents a challenge to explain how and why it works.

Figure 30: Design-science activities

Next, we explore literature review by taking a look at a cognitive model of design processes
as describe by (Hideaki Takeda, 1990). Their work examined a design process from a
problem-solving point of view, and they formulated a model for a design process. This model
is constructed from unit design cycles. The design cycle consists of five sub processes as
shown in the diagram below:

Figure 31: Design processes

Explanations for above process are as follows:
1. Awareness of the problem: to pick up a problem by comparing the object under
consideration with the specifications, enumeration of problems, and decide on a
problem to be solved;
Build Evaluate
Awareness Suggestion Development Evaluation Conclusion
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 44 of 161




Aldo Elam Majiah

2. Suggestion: to suggest key concepts needed to solve the problem;
3. Development: to construct candidates for the problem from the key concepts using
various types of design knowledge;
4. Evaluation: to evaluate candidates in various ways, such as structural computation,
simulation of behavior, and cost evaluation. This evaluation confirm the solution;
5. Conclusion: to decide which candidate to adopt, modifying the descriptions of the
object. It concludes on a solution to be adopted and decide on action to be done next.
In order to elaborate the process of design in a clearer way and closer to real-world situation,
(Hideaki Takeda, 1990) distinguished two levels in the design process when they considered
the designers mental activity. One is the object level, where the designer thinks about design
objects themselves, for example, what properties the design object has and how it behaves in
a certain condition. The other is the action level, where the designer thinks about how to
proceed with his (her) design, that is, what s/he should do next. Next figure shows the two
mental activities (object and action) in relation to a design process cycle.

Figure 32: Design cycle in relation to mental activities

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 45 of 161




Aldo Elam Majiah

We can see that process that relates Development Evaluation is a cycle. This process is
aligned with design process called Build and Evaluate as described by design science
(Salvatore T. March, 1995). Hence this Build and Evaluate cycle can be achieved by
utilizing IT artifacts.
(Walls, 1992) defines design as both process (a set of activities) and a product (artifact).
While (Salvatore T. March, 1995) elaborates the processes as build and evaluate, and the
artifacts as constructs, models, methods, and instantiations.
Aligned with March and Takeda, (Alan R. Hevner, 2004) shows that in design science,
knowledge and understanding of a problem domain and its solution are achieved in the
building and application of the designed artifact. However, designing useful artifacts is
complex due to the need for creative advances in domain areas in which existing theory is
often insufficient. Hence, they described a conceptual framework and clear guidelines for
understanding, executing, and evaluating design science research. The guidelines for creating
IT artifacts are as follows (Alan R. Hevner, 2004):
Table 3: Design-science guidelines (Alan R. Hevner, 2004)
Design-Science Research Guidelines
Guideline Description
Guideline 1: Design as an artifact Design-science research must provide a viable artifact in the form of
construct, a model, a method, or an instantiation.
Guideline 2: Problem relevance The objective of design-science research is to develop technology-
based solutions to important and relevant business problems.
Guideline 3: Design evaluation The utility, quality, and efficacy of a design artifact must be rigorously
demonstrated via well-educated evaluation methods.
Guideline 4: Research contributions


Effective design-science research must provide clear and verifiable
contributions in the areas of the design artifact, design foundation,
and / or design methodologies.
Guideline 5: Research rigor Design-science research relies upon the application of rigorous
methods in both the construction and evaluation of the design
artifact.
Guideline 6: Design as a search process The search for an effective artifact requires utilizing available means
to reach desired ends while satisfying laws in the problem
environment.
Guideline 7: Communication research Design-science research must be presented effectively both to
technology-oriented as well as management-oriented audiences.

One of the difficulties of design science is projecting mental model of the process, especially
for IT and IS related research such as one conducted in this thesis. This problem was
addressed by (Ken Peffers, 2006), they provided a new model of design science research to
be used specifically in the IS world. This model had three objectives: was consistent with
prior literature, providing a nominal process model for doing DS research, and providing a
mental model for presenting and appreciating DS research in IS. The model was called DSRP
and included six steps of processes: problem identification and motivation, objectives for a
solution, design and development, demonstration, evaluation, and communication.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 46 of 161




Aldo Elam Majiah



Figure 33: DSRP Model (Ken Peffers, 2006)

Brief explanations of the six processes are as follows:
1. Problem identification and motivation. Define the specific research problem and justify
the value of a solution. Resources required for this activity include knowledge of the
state of the problem and the importance of its solution.
2. Objectives of a solution. Infer the objectives of a solution from the problem definition.
The objectives should be inferred rationally from the problem specification.
3. Design and development. Create the factual solution. Such artifacts are potentially, with
each defined broadly, constructs, models, methods, or instantiations.
4. Demonstration. Demonstrate the efficacy of the artifact to solve the problem. This could
involve its use in experimentation, simulation, a case study, proof, or other appropriate
activity.
5. Evaluation. Observe and measure how well the artifact supports a solution to the
problem. This activity involves comparing the objectives of a solution to actual
observed results from use of the artifact in the demonstration.
6. Communication. Communicate the problem and its importance, the artifact, its utility
and novelty, the rigor of its design, and its effectiveness to researchers and other
relevant audiences, such as practicing professionals, when appropriate.
The DSRP model is suitable to be used in IS research. The processes and steps described in
the model are specifically developed for DS research in the world of IT. Hence this model is
used in this research as the basis of research methodology.

2.6 Theoretical framework
The overall methodology for the thesis is taken from DSRP model from (Ken Peffers, 2006).
For design and development part, we will use AD risk assessment framework as a method for
developing IT artifacts. The methodology and theoretical framework diagram is shown in
figure 34:
Problem
identification
and motivation
Objectives of a
solution
Design &
development
Demonstration Evaluation Communication
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 47 of 161




Aldo Elam Majiah


Figure 34: Methodology and theoretical framework

For the risk assessment framework, we are using AD risk assessment framework which has
seven steps as shown in figure 34. This AD risk assessment framework will be conducted on
six AD components which represent characteristics of AD. Figure 35 shows representation of
AD risk framework on AD components.

Figure 35: AD components revolves around risk assessment framework
AD risk
assessment
framework
AD design &
boundary
AD
management
Policy
implementation
Security of AD
computer
members
Security of
network
Security of DC
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 48 of 161




Aldo Elam Majiah

CHAPTER 3 - RESEARCH METHODOLOGY
The way in which this research is conducted will follow methodology shown in the figure
below. The methodology is derived using DSRP model from (Ken Peffers, 2006).

Figure 36: Thesis methodology
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 49 of 161




Aldo Elam Majiah

3.1 Steps of research methodology
Detailed steps are as follows:
1. Define research problem and objectives. Problems in performing a secure
implementation of Active Directory in most enterprises were presented using fishbone
diagram. Probable causes of the problem were identified. Author then select a particular
problem area for thesis topic and developed research questions and research objectives.
2. Conduct literature review. Literature reviews on related sources were conducted,
resulting in theoretical framework for answering the research questions. The result of
this step is a risk assessment framework for assessing AD. AD was also divided into six
components to ease the finding of the threats.
3. Data gathering. Data gathering was conducted in a real AD implementation in an
organization. The data gathering activities followed (NIST, 2002), in which it stated
that techniques that can be used for data gathering are: questionnaire, on-site interviews,
document review, and use of automated scanning tools. The author performed on-site
interview, automated vulnerability scan, and penetration testing in the organization.
4. Design and development using theoretical framework. AD risk assessment framework
was used on six components of AD implementation in the organization. The result of
this activity is a set of recommended countermeasures for AD security implementation
in the said organization.
5. Demonstrate countermeasures. The countermeasures recommended from previous step
were demonstrated to measure their effectiveness. The demonstration was conducted in
a prototype AD environment of the organization.
6. Evaluate. Experts judgments were used to validate AD risk framework, AD
components, and countermeasure results. Lastly, conclusion and on the research and
suggestion on future works were presented.

3.2 Key activities for design and development
The following are key activities of the theoretical framework against AD components.
3.2.1 AD system characterization
In this step we perform identification of the AD, along with the resources and the information
that constitute the system (NIST, 2002). AD system characterization establishes the scope of
risk assessment, defines operational boundaries, and provides information (hardware,
software, network connectivity, and responsible division or PIC). All of these are essential for
defining the risk.
There are several researches related with developing activities for AD system
characterization and threat identifications. Research from (ISACA, 2010) is one of them; it
defines activities for auditing AD and has detailed auditing questions and scenarios.
Unfortunately, this research does not include audit of AD servers and workstations computer
members which build the larger part of AD domain. It also does not include audit of Domain
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 50 of 161




Aldo Elam Majiah

Name Service (DNS) management which usually becomes first target of attackers who are
trying to enumerate list of all computers members in an AD.
On the other hand, there are researches which are focused on the security of computers in the
network. (Sandberg, 2013)s research points out a minimal set of technical countermeasures
for securing endpoints computers or devices. These sets are: inventory of hardware and
software, patch management, security configuration management, mobile devices
management if the organization is using mobile devices as endpoints. Likewise, (Center for
Strategic and International Studies, 2013) and (Defence Signals Directorate, 2012) describe
sets of mitigation strategies for securing computers in the network.
In AD system characterization step, we will define the characterization of AD into six
components as previously described in chapter 2.1.3. These activities are derived from
literature reviews with the emphasis from the researches that have been discussed above:
(ISACA, 2010), (Sandberg, 2013), (Center for Strategic and International Studies, 2013), and
(Defence Signals Directorate, 2012). There are 64 key activities or characterization of the AD
system that need to be performed. These activities are divided into six AD components; AD
design & boundary has 6 key identification activities, AD management has18 activities,
policy implementation has 6, security of AD computer members has 17, security of network
component has 8, and the last component is security of DC which has 9 key identification
activities.

Figure 37: Distribution of key identification activities

6
18
6
17
8
9
Key activities
AD design & boundary
AD management
Policy implementation
Security of AD computer
members
Security of network
Security of DC
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 51 of 161




Aldo Elam Majiah

Key activities for each component are as follows:
AD design & boundary:
Identify forest and domain structure (for example: the implemented AD is single forest,
multiple domains).
Obtain a hierarchal diagram representation of the AD structure, starting with the forest
down to domain.
Review of forest or domain trust relationship(s) and determine that external trusts are
permitted only with prior authorization.
Determine whether there are appropriate administrative controls to prevent
unauthorized granting of trusts.
Review AD design documentation.
Determine if the forest or domain structure provides for a separation between service
administrators, considering administrative and security boundaries between
forest/domain administrators.
AD management:
Identify domain and forest functional level.
Identify servers holding FSMO roles.
Identify domain tree structure.
Determine if OU deployment has already aligned with organizations structure.
Determine if security group deployment has already aligned with organizations needs.
Identify the organizations personnel responsible for AD, considering personnel
capabilities, workload, skills, and separation of duties.
Review existing AD documentations (policies, logs, previous audit, etc).
Determine if high privilege accounts groups are controlled (for example Domain
Admins, Enterprise Admins, and Schema Admins groups).
Review delegation of tasks to groups/accounts.
Review if separation of daily accounts and administrative accounts exists.
Identify accounts used for service, applications, or other accounts which passwords are
rarely changed.
Identify restricted groups.
Identify existing change management for AD.
Review AD log monitoring capabilities.
Determine if AD functional level (forest or domain) is already the highest for DCs
operating system.
Review AD availability (existence of secondary / backup domain controller) for each
site.
Determine if there are backup procedures for AD.
Check whether there are periodic restore testing procedures for AD backup.

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 52 of 161




Aldo Elam Majiah

Policy implementation:
Identify whether existing OU deployment is suitable for GPO implementation.
Review of security settings policy implementation: Account policies (password
policies, account lockout policy, Kerberos policy).
Review of security settings policy implementation: audit policy.
Review of security settings policy implementation: user rights assignments.
Review of security settings policy implementation: security options.
Review of security settings policy implementation: event log.
Security of AD computer members:
Identify patch management system (patch for OS and applications).
Identify existence of application whitelisting (permitted applications) in servers and
workstations.
Identify controlled used of administrative privilege.
Identify if there is secure configurations or procedures for deploying servers and
workstations (for example: disabling unrequired applications or services, patching
before deploying servers or workstations).
Identify correct deployment of anti-virus and anti-malware software (check if antivirus
software has been installed, determine if antivirus software can be disabled or removed,
check if the signature files are updated regularly).
Identify removable and portable media control.
Identify continues vulnerability scanning processes for AD computer members.
Identify data recovery capability.
Identify whether host-based firewall is configured.
Identify whether there users education and awareness.
Identify whether LanMan is still used on servers/ workstations.
Identify whether there are security-related incidents in helpdesk logs.
Identify exploits and attacks.
Identify users related threats.
Identify natural threats.
Identify hardware related threats.
Identify if virtual machine environment is used
Security of network:
Identify wireless AP network segregation.
Review whether there are secure network configurations documents for network
devices (such as firewalls, routers, and switches).
Identify whether network ports, protocols, and services are limited and controlled.
Identify network segmentation / segregation.
Identify the use of network based intrusion detection / prevention system.
Identify the use of website blacklisting in the proxy.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 53 of 161




Aldo Elam Majiah

Determine if the cabling rooms are locked with limited access and the access are
logged.
Determine if management ports of domain controllers and servers (RDP, SSH) are
connected to a dedicated management network (segmented from other networks and
only admin workstations can connect to them).
Security of DC:
Determine if all DCs have already the latest security patches / service packs.
Identity if there are secure configuration documentations or procedures for deploying
DC.
Check whether DC is placed in a secure physical facility.
Identify correct deployment of anti-virus and anti-malware software on DC (check if
antivirus software has been installed, determine if antivirus software can be disabled or
removed, check if the signature files are updated regularly).
Identify whether DC runs only essential services or features.
Determine whether only authorized personnel are allowed to access DC physically.
Determine if DC is using a backup power supply (UPS).
Determine if DC can be booted using alternative OS.
Determine if DC is using a secure out-of-band management network.

3.2.2 Threat sources and events identification
In this step we will identify both threat sources and events. Identifying threat sources
comprise of identifying threat sources from point of view capability, intent, and targeting
characteristics (NIST, 2012). The focus of this step is on identifying possible IS threats.
These threats are sources, events, actions, or inactions that could harm of the organization
(Mark RM Talabis, 2013).
Key activities:
Identify threat sources
Identify threat events
Determine and assess the relevance of threat sources to AD implementation in the
organization
Determine and assess the relevance of threat events to AD implementation in the
organization

3.2.3 Identification of vulnerability
Using output from previous activities of finding threats sources and events, next we deal with
identifying vulnerabilities that can be leveraged by these threat sources and events and
produce threat and vulnerability pair (Mark RM Talabis, 2013). (NIST, 2012) states that there
could be a many-to-many relationship between threat events and vulnerabilities. Multiple
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 54 of 161




Aldo Elam Majiah

threat events can exploit a single vulnerability and multiple vulnerabilities can be exploited
by a single threat event.
Key activities:
Identify vulnerabilities, taken into account data from questionnaires, automated
vulnerability scan, and penetration testing report.

3.2.4 Determination of likelihood of occurence
Key activities, taken from (NIST, 2012):
Define assessment table for likelihood of event initiation or occurrence.
Define assessment table for threat event resulting in impact.
Determine and assess overall likelihood
Table 4: Table for likelihood of event initiation or occurrence (NIST, 2012)
Value Description
5 (very high) Adversary is almost certain to initiate the threat event or error, accident, or act of nature is almost
certain to occur; or occurs more than 100 times a year
4 (high) Adversary is highly likely to initiate the threat event or error, accident, or act of nature is highly
likely to occur; or occurs between 10-100 times a year.
3 (moderate) Adversary is somewhat likely to initiate the treat event or error, accident, or act of nature is
somewhat likely to occur; or occurs between 1-10 times a year.
2 (low) Adversary is unlikely to initiate the threat event or error, accident, or act of nature is unlikely to
occur; or occurs less than once a year, but more than once every 10 years.
1(very low) Adversary is highly unlikely to initiate the threat event or error, accident, or act of nature is highly
unlikely to occur; or occurs less than once every 10 years.

Table 5: Table for likelihood of threat event resulting in impact (NIST, 2012)
Value Description
5 (very high) If the threat event is initiated or occurs, it is almost certain to have adverse impacts
4 (high) If the threat event is initiated or occurs, it is highly likely to have adverse impacts
3 (moderate) If the threat event is initiated or occurs, it is somewhat likely to have adverse impacts
2 (low) If the threat event is initiated or occurs, it is unlikely to have adverse impacts.
1(very low) If the threat event is initiated or occurs, it is highly unlikely to have adverse impacts.

Table 6: Table for determining/assessing overall likelihood (NIST, 2012)
likelihood of
event
initiation or
occurrence:
likelihood of threat event resulting in impact:

1(very low) 2 (low) 3 (moderate) 4 (high) 5 (very high)
5 (very high) 2 3 4 5 5
4 (high) 2 3 3 4 5
3 (moderate) 2 2 3 3 4
2 (low) 1 2 2 3 3
1(very low) 1 1 2 2 2


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 55 of 161




Aldo Elam Majiah

3.2.5 Determination of impact magnitude
Key activities, taken from (NIST, 2012):
Define assessment table for assessing impact of threat events
Determine and assess impact
Table 7: Table for assessing impact of threat events (NIST, 2012)
Description
5 (very high) The threat event could be expected to have multiple severe or catastrophic adverse effects on
organizational operations, organizational assets, individuals, other organizations, or the Nation.
4 (high) The threat event could be expected to have a severe or catastrophic adverse effect on
organizational operations, organizational assets, individuals, other organizations, or the Nation. A
severe or catastrophic adverse effect means that, for example, the threat event might: (i) cause a
severe degradation in or loss of mission capability to an extent and duration that the organization
is not able to perform one or more of its primary functions; (ii) result in major damage to
organizational assets; (iii) result in major financial loss; or (iv) result in severe or catastrophic harm
to individuals involving loss of life or serious life-threatening injuries.
3 (moderate) The threat event could be expected to have a serious adverse effect on organizational operations,
organizational assets, individuals other organizations, or the Nation. A serious adverse effect
means that, for example, the threat event might: (i) cause a significant degradation in mission
capability to an extent and duration that the organization is able to perform its primary functions,
but the effectiveness of the functions is significantly reduced; (ii) result in significant damage to
organizational assets; (iii) result in significant financial loss; or (iv) result in significant harm to
individuals that does not involve loss of life or serious life-threatening injuries.
2 (low) The threat event could be expected to have a limited adverse effect on organizational operations,
organizational assets, individuals other organizations, or the Nation. A limited adverse effect
means that, for example, the threat event might: (i) cause a degradation in mission capability to
an extent and duration that the organization is able to perform its primary functions, but the
effectiveness of the functions is noticeably reduced; (ii) result in minor damage to organizational
assets; (iii) result in minor financial loss; or (iv) result in minor harm to individuals.
1(very low) The threat event could be expected to have a negligible adverse effect on organizational
operations, organizational assets, individuals other organizations, or the Nation.

3.2.6 Risk determination
Determining risk level from threat events while considering both the likelihood and impact
magnitude of the events (NIST, 2012).
Key activities:
Define assessment table for determining level risk as combination of likelihood and
impact.
Describe level of risk assessment.
Determine and assess risk.
Table 8: Table for determining level risk as combination of likelihood and impact (NIST, 2012)
Likelihood Impact

1(very low) 2 (low) 3 (moderate) 4 (high) 5 (very high)
5 (very high) 1 2 3 4 5
4 (high) 1 2 3 4 5
3 (moderate) 1 2 3 3 4
2 (low) 1 2 2 2 3
1(very low) 1 1 1 2 2


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 56 of 161




Aldo Elam Majiah

Table 9: Table for describing level of risk assessment (NIST, 2012)
Value Description
5 (very high) Very high risk means that a threat event could be expected to have multiple severe or catastrophic
adverse effects on organizational operations, organizational assets, individuals, other
organizations, or the Nation.
4 (high) High risk means that a threat event could be expected to have a severe or catastrophic adverse
effect on organizational operations, organizational assets, individuals, other organizations, or the
Nation.
3 (moderate) Moderate risk means that a threat event could be expected to have a serious adverse effect on
organizational operations, organizational assets, individuals, other organizations, or the Nation.
2 (low) Low risk means that a threat event could be expected to have a limited adverse effect on
organizational operations, organizational assets, individuals, other organizations, or the Nation.
1(very low) Very low risk means that a threat event could be expected to have a negligible adverse effect on
organizational operations, organizational assets, individuals, other organizations, or the Nation.

3.2.7 Countermeasure recommendation
Providing controls for mitigating or eliminating risks from previous step. The output of this
step is recommendation of controls / countermeasure for each identified risks or alternative
solutions for mitigating the risk (NIST, 2002).
Key activities:
Recommend countermeasure for each risk, taking into consideration effectiveness of
recommended options (system compatibility), legislation and regulation, organizational
policy, operational impact, and safety and reliability.

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 57 of 161




Aldo Elam Majiah

CHAPTER 4 RISK ASESSMENT & ANALYSIS
4.1 Design and development (risk assessment)
4.1.1 AD system charaterization
These are data from risk assessment step 1, characterizing AD. The organization where the
data was taken from is an educational institution organization, throughout this thesis it will be
referred as organization. The data were taken using the following techniques: peer-to-peer
interviews, automated vulnerability scan, and penetration testing. These data are confidential;
hence the omitting of the organization name, involved personnel, and other infrastructure
information will be conducted if deemed necessary.
Original forms and edited versions of AD characterization assessments are available in the
appendix (appendix 1 and 2). Penetration testing report and result of automated vulnerability
scanning are disclosed partially and carefully in chapter 4.1.3, identification of vulnerability.
The whole system characterization processes took about 5 working days on March 2014. It
included a penetration testing activity and automated vulnerability scan of the organizations
entire network. The creation of penetration testing report for the organization took an
additional of 2 weeks time.
To perform the penetration testing and vulnerability scan of the network, the author was
provided with a WIFI access from a library inside the organizations premises. This WIFI
access turned out to be connected to the entire organizations network.
For penetration testing activity, the author used many tools which are mainly provided in Kali
Linux. Kali Linux is a Debian-based Linux distribution designed for penetration testing. It
consists of hundreds of penetration testing tools. Some of these tools, for example nmap,
Metasploit framework, and nbtscan, were heavily used during this activity. The author also
used a vulnerability scanning tool, Nessus. Nessus is a remote vulnerability scanning tool,
which scans a computer and raises an alert if it discovers vulnerabilities on the target systems.
Questionnaires to the organization were conducted at the end of the penetration testing
project. The organization was presented by three IT personnel; IT system administrator, GA
& IT manager, and IT supervisor. Most of the answers from the questionnaires were provided
by the system administrator.

4.1.2 Threat sources and events identification
These are relevant threat sources and events related to the organization in general and in
particular to AD implementation in the organization.
To help identifying threat sources, first we shall introduce threat sources taxonomy from
(NIST, 2012):
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 58 of 161




Aldo Elam Majiah

Table 10: Threat sources taxonomy (NIST, 2012)
Type of threat sources Description
ADVERSARIAL
- Individual
- Outsider
- Insider
- Trusted Insider
- Privileged Insider
- Group
- Ad hoc
- Established
- Organization
- Competitor
- Supplier
- Partner
- Customer
- Nation-State
Individuals, groups, organizations, or states that seek to exploit the
organizations dependence on cyber resources (i.e., information in
electronic form, information and communications technologies, and the
communications and information-handling capabilities provided by
those technologies).
ACCIDENTAL
- User
- Privileged User/Administrator
Erroneous actions taken by individuals in the course of executing their
everyday responsibilities.
STRUCTURAL
- Information Technology (IT) Equipment
- Storage
- Processing
- Communications
- Display
- Sensor
- Controller
- Environmental Controls
- Temperature/Humidity Controls
- Power Supply
- Software
- Operating System
- Networking
- General-Purpose Application
- Mission-Specific Application
Failures of equipment, environmental controls, or software due to aging,
resource depletion, or other circumstances which exceed expected
operating parameters.
ENVIRONMENTAL
- Natural or man-made disaster
- Fire
- Flood/Tsunami
- Windstorm/Tornado
- Hurricane
- Earthquake
- Bombing
- Overrun
- Unusual Natural Event (e.g., sunspots)
- Infrastructure Failure/Outage
- Telecommunications
- Electrical Power
Natural disasters and failures of critical infrastructures on which the
organization depends, but which are outside the control of the
organization.
Note: Natural and man-made disasters can also be characterized in
terms of their severity and/or duration. However, because the threat
source and the threat event are strongly identified, severity and
duration can be included in the description of the threat event (e.g.,
Category 5 hurricane causes extensive damage to the facilities housing
mission-critical systems, making those systems unavailable for three
weeks).

Next, to help identifying threat events, we derive a list of threat events. Some of the threats
events were taken from (NIST, 2012), others were taken from Microsofts GPO
implementation, but most of them are created by the author. Each of these threats has
identification number which will be used in subsequent steps.
Overall, there are 221 threat events divided into six AD components as shown in figure 38.
Six threats identified in AD design and boundary, 19 threats identified in AD management,
80 threats identified in policy implementation, 77 threats in security of AD computer
members, 26 threats identified in security of network, and 13 threats identified in security of
DC.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 59 of 161




Aldo Elam Majiah


Figure 38: Distribution of threat events
Details of threat events, its description, and identification number of each threat are described
in detail in appendix 3.

4.1.3 Identification of vulnerability
To identify the vulnerability of each threat, the author takes consideration of interview result
of AD system characterization (appendix 1 and 2), vulnerability scanning report, and
penetration testing report for that has been performed for the organization.
There were 129 hosts scanned by Nessus vulnerability scanner (Majiah, 2014). The
automated scanning by vulnerability scanner found a total of 189 vulnerabilities. The scanner
automatically categorized these vulnerabilities into five groups, based on their severity level:
critical, high, medium, low, and info (information only). Critical vulnerabilities was detected
as many as 6% of all detected vulnerabilities, high 11%, medium 22%, low 6%, and the rest
was categorized as information (56%).

Figure 39: Vulnerability scan results

6
19
80
77
26
13
Identified threats
AD design and boundary
AD management
Policy implementation
AD computer members
Security of network.
Security of DC
Critical, 6
High, 11
Medium ,
22
Low, 6
Informatio
nal, 56
Vulnerabilities
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 60 of 161




Aldo Elam Majiah

The critical vulnerabilities were dominated by missing Windows OS patches (7 critical
missing patches detected on 20 hosts) and Apache-related vulnerabilities (2 vulnerabilities on
4 hosts). Vulnerabilities with high severity level were dominated by PHP-related
vulnerabilities (13 vulnerabilities detected on 45 hosts).
Penetration testing resulted in total complete took over of the Active Directory. Pen-tester
was able to acquire a high privilege domain accounts through brute force attack on the
domain controller. There were a total of 16 findings reported on the penetration testing report
(Majiah, 2014), with two findings categorized as high risk. Six of these findings related
directly to AD implementation in the organization network. Related findings to AD were
finding no. 1, 2, 3, 4, 8, and 9 as shown figure 39.

Figure 40: Summary of penetration testing report

The identification of vulnerabilities in relation to the threats events are described in detail in
appendix 4. Most of the vulnerabilities in the organizations AD were caused by weak
implementation of password policies, unimplemented security GPOs, availability problem,
and incomplete patch management on domain computers. Please note that appendix 4 uses
the same threat identification numbering as defined in appendix 3.

4.1.4 Determination of risk level and countermeasure
Next we determine the likelihood, impact, risk level, and at last the countermeasure for the
threat. These steps are defined in section 3.2.4 to 3.2.7. In those sections we can see the
definition of each level of likelihood, impact, and risk level. Matrix for determining overall
risk is also provided in chapter 3.2.6. All the results are presented in appendix 5.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 61 of 161




Aldo Elam Majiah

The result of the risk assessment is shown in the figure below. For AD implementation on the
organization there were 5 very high risk threats, 21 high risk threats, and 79 moderate threats.
The rest of the threats have low (86 threats) and very low risks (30 threats).

Figure 41: Risk assessment result

The final risk level is categorized into five levels as described in section 3.2.6 where risk
assessment levels (very low, low, moderate, high, and very high) are clearly defined. Risk
level for very low and low risk will be assumed as accepted by the organization; hence
countermeasures are not defined for these two levels. Countermeasures are given for risks
that could cause serious effects to the organization, which are moderate, high, and very high
risks (assumed). For details on the risk level of each threat and the countermeasure
recommendations, please refer to appendix 5.

4.2 Demonstrate countermeasure (prototyping)
In this subchapter the author select several countermeasures and implement them in a virtual
machine environment for testing purposes and demonstrating its effectiveness. It was not
possible to implement the countermeasures directly in the original AD environment because
it may have implications in the production network.
But demonstrating countermeasure is a step in the methodology, hence it must be done. Thus
the author selected a virtual machine environment to show the implementation of these
countermeasures. To achieve this, the author created an exact replica of the domain under
assessment. This AD replica was created during penetration testing activity by promoting a
VM to a secondary DC. This secondary DC then used in prototyping the countermeasures.
0
10
20
30
40
50
60
70
80
90
100
VERY HIGH HIGH MODERATE LOW VERY LOW
Risk assessment results
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 62 of 161




Aldo Elam Majiah

It is also worth noted that not all countermeasures are tested; only countermeasures which are
technical in nature and are possible to be implemented in a VM environment are selected.
Other countermeasures, such as the ones related to implementation of policies or users
training cannot be implemented and measured in virtual machines environment, instead they
have to be implemented for the users in the original environment and its effectiveness also
cannot be measured in a short time.
The AD for this demonstration consists of approximately of 800 users and 370 computers.
This is a single domain, single forest AD that does not have trust relationship with other
entities. The AD has only one site, the default-first-name-site.

Figure 42: AD for prototyping

Disable booting from alternative OS
If BIOS is not protected then adversaries may shutdown a host (or DC) and gain
access to sensitive files such as SAM account files. SAM account files are files where
database of user accounts are saved. If an adversaries could get these files, than he/she
may be able to perform offline password cracking. The following screenshots show
how an adversaries boot a DC using alternative bootable CD, access, and copied the
ntds.dit and system security files out of the DC.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 63 of 161




Aldo Elam Majiah


Figure 43: Access files using alternative OS
After the files are copied outside, adversaries could extract password hashes out of these files
and crack them using offline password cracking program such as Ophcrack as shown in
figure 44.

Figure 44: Offline password cracking using Ophcrack
To thwart this threat, administrators need to disable booting using portable USB or CD/DVD
media in the BIOS and protect BIOS using password.

Upgrade to higher domain and forest functional level
DC in an AD can run different versions of Windows Server OS. The functional level of a
domain or forest depends on which versions of Windows Server OS are running on the DC in
the domain or forest, it also controls which advanced features are available in that domain or
forest. Raising the functional level allows the introduction of advanced features, including
newer security features, but also limits the versions of Windows Server that can run on
domain controllers in the environment. AD DS has two types of functional levels: domain
functional level and forest functional level (Microsoft, 2010).
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 64 of 161




Aldo Elam Majiah

The organization has a single DC that runs on Windows Server 2008 but the functional level
is 2003. To upgrade domain functional level, simply right click at the domain name in the
ADUC and select raise domain functional level. Likewise, to raise forest functional level,
simply right click ADDT and select raise forest functional level.
Raising functional level to 2008 introduces newer security features such as; fine-grained
password policies which enables specify password and account lockout policies for users and
global security groups in a domain, increased Kerberos encryption using AES 128 and 256,
accidental deletion protection feature for AD objects, and interactive failed logon
information.

Figure 45: raising functional levels

Create secondary DC
Creating a secondary DC in the domain improves the availability and reliability of domain
services. It also provides fault tolerance, load balancing between DC, and additional
infrastructure support for the sites. A single DC means the DC becomes a liability as it
functions as single-point-of-failure.
Figure 46 shows additional domain controller is added for the site, efficiently thwarting
availability risk for AD. The hostnames of the DCs are 2k3pentest and 2k8pt, serving default-
first-site-name of xxxjkt.com domain.

Figure 46: Primary and secondary DC
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 65 of 161




Aldo Elam Majiah

In addition to provide solution to AD availability problems, a secondary DC can also function
as a backup of FSMO roles. FSMO is five special roles, two per domain and three per forest,
which are vital to ensure the smooth running of AD. The forest roles are schema and domain
naming master; while domain roles are RID, PDC emulator, and infrastructure master.
Screenshot below shows a successful transfer of RID master role into another DC, which will
not be possible if the organization does not have a secondary DC.

Figure 47: Successfully transferred RID master role

Create computer-based OU
To ease deployment of GPO, the organization needs to deploy OU based on the computer
functions (e.g. servers and workstations), in addition to existing user-based OUs. Screenshot
below shows the implementation of such OUs; computers are categorized into servers and
workstations, and workstations are further categorized as teachers_computers, library, lab, etc

Figure 48: Computer-based OU deployment
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 66 of 161




Aldo Elam Majiah

Limit & control high privilege domain accounts
The amounts of high privilege domain accounts (enterprise admin, schema admin, and
domain admin accounts) are too high. Reducing the number of current domain admins from 8
accounts into only 3 accounts will provide better control on them.

Figure 49: Reduce number of domain admins
Controlling the use of high privilege domain accounts is also necessary to mitigate the pass-
the-hash attack, a kind of attack that arises due to the fact that password hashes are never
salted in Windows environment. In this attack, usually high privilege domain accounts, i.e. a
domain admin account, is targeted. Once a domain admin account is compromised, an
adversary can use this high privilege domain accounts to move from one host to another.
Since domain admins accounts are usually have strong passwords, adversaries may not be
able to crack the hash and found the original plaintext. But since pass-the-hash attack is
invented, it is not necessary to know the password, knowing the hash is sufficient. It gives
adversaries a way to compromise all computer member of the domain since domain admins
are members of administrator groups in all AD computer member by default.
As an example, we configure a domain admin account aldoel to be able to logon from one
host only, 2k3pentest.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 67 of 161




Aldo Elam Majiah


Figure 50: Configure an account ability to logon from only one host

Next, we assume that an adversary has compromised this aldoel domain admin account and
already acquired the hash of this account. The adversary then tries to comprise host
192.170.153.158 using the hash from the account using metasploit. The attempt fails as
shown in figure below because the account is not configured to be able to logon to that host.

Figure 51: Fail pass-the-hash attack

Utilize the use of restricted groups
Instead of using high privilege domain accounts such as domain admins for troubleshooting
or installing applications on workstations, we can utilize the use of restricted groups.
Screenshot below shows an example of deployment of a restricted group called helpdesk as
administrator in workstations. The group is deployed utilizing GPO to all workstations in the
domain to ensure the helpdesk group administrative access to all workstations.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 68 of 161




Aldo Elam Majiah


Figure 52: Deploying restricted group
Utilizing this feature, helpdesk group has become member of administrators group in all
workstation thus enabling helpdesk team to troubleshoot users workstation with
administrative privilege without using a domain admin account.

Separate account for administrators
To minimize the use of high privilege accounts such as domain admin accounts, it is best to
create two accounts for domain administrators. One account is a normal user account for
performing daily task for the administrator (browsing, creating office documents, etc), and
the other one is a high privilege account. For example, we can create a normal user aldoel
and aldoel-adm as the domain admin account. Every time the administrator needs to perform
domain related tasks that needs a domain admin privilege, he can utilize run as command.

Figure 53: Using run as for administrative tasks
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 69 of 161




Aldo Elam Majiah

Implement secure password policies
Password policy of the organization was found very lacking. Password complexity was not
enabled, and minimum password length was only 3 characters.

Figure 54: Weak password policy

This weak password policy created basic password problems; penetration testing result
showed the following weak domain users passwords:
1. Passwords which were the same as the usernames: 75 instances.
2. 233 domain users were using 123 as the password of their accounts.
3. 6 domain users were using 1234 as the password of their accounts.
4. 4 domain users were using 12345 as the password of their accounts.
5. 3 domain users were using 123456789 as the password of their accounts.
6. 2 domain users were using 12345678 as the password of their accounts.
7. 3 domain users were using password as the password of their accounts.
8. 366 domain users were using 4 character password or less than 4 characters.
Screenshot below shows a more secure password policy implementation. A minimum
password length of 8 characters and password complexity are implemented. Password history
and maximum password age are reduced to 10 and 30 days, respectively. Implementing
stronger password policy such as this should eliminate password problems found during
penetration testing. A regular check of domain user passwords, e.g. once every 6 months, is
necessary to ensure all domain users are free of weak password problems.

Figure 55: Stronger password policy
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 70 of 161




Aldo Elam Majiah

Implement secure account lockout policies
A strong account lockout policy can frustrate adversaries who perform brute force attack on
domain accounts. Current account lockout policy of the organization proved to be weak as
only one policy was implemented; the account lockout threshold was set to 0.

Figure 56: Weak account lockout policy

This weak policy enabled the penetration tester to perform brute force attack using medusa.
Medusa is an online password brute force application, it is described as a speedy login brute
force application with modules available to support almost any service that allows remote
authentication using a password, including: FTP, HTTP, CVS, MySQL, POP3, IMAP, MS-
SQL, PostgreSQL, VNC, SMTP-AUTH, and Telnet.
Figure 57 shows real penetration testing activity on the organizations domain controller.
Penetration tester performed brute force attack SMB account passwords on the domain
controller and found weak passwords used in many domain accounts.

Figure 57: Password cracking using Medusa

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 71 of 161




Aldo Elam Majiah

It is imperative to implement stronger account lockout policy to minimize the possibility of a
successful brute force attack on domain users passwords. Account lockout threshold was set
to 3 invalid logon attempts. This means after 3 times of incorrect password attempt, the
account is locked out. The account is locked out for 30 minutes and then it releases back, as
described in Account lockout duration policy. This policy, together with Reset account
lockout counter after policy, helps a possibility to undo mass account lockout after 30
minutes if a brute force attack is underway.

Figure 58: Stronger account lockout policy

To test the effectiveness of this feature, we tried the same password brute force attack using
medusa. The result showed that the account being brute forced was locked out after 3 invalid
password brute force attempt. The new account lockout policy was a success.

Figure 59: Testing account lockout policy

Perform regular AD backup
Perform AD backup regularly is as important as testing the backup result in also a scheduled
restore testing process. We can backup AD using default Windows server backup feature
since Active Directory is backed up as part of system state. Third party AD backup software
which offers more functionality is also available in the market.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 72 of 161




Aldo Elam Majiah

System state includes AD and all other system components and services on which AD is
dependent. It consists of system startup files, File Replication service (the SYSVOL
directory), system registry, COM+ class registration database, certificate Services database,
DNS, Cluster service and the AD itself. DNS data includes Active Directoryintegrated DNS
zone information. AD data consist of the following: AD database (ntds.dit), checkpoint file,
transaction logs and reserved transaction logs.

Figure 60: Backup AD using Windows Server backup

Automatic patch management system
Ensure all OS are receiving updates. For Windows system, this can be done by setting
automatic update to check and install patches directly from Microsoft or, preferably, using a
WSUS server deployment.
WSUS enables IT administrators to deploy latest Microsoft patch updates to computers
running the Windows OS. By using WSUS, administrators can manage distribution of
updates released through Microsoft Update to computers in their network (Microsoft, 2014).
There are two general steps when deploying WSUS server: deploy the server and distribute
patch update configuration using GPO. As an example, say we have deployed a WSUS server
in IP address 192.170.153.155. To ensure uniform configuration throughout the domain,
administrators need to configure all computers in the domain to update the patch using this
WSUS server. This can be done via GPO, as shown in the next figure.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 73 of 161




Aldo Elam Majiah


Figure 61: WSUS configuration GPO

Administrators also need to check regularly computers that are not correctly receiving and
installing patches intended for them. This information can be viewed from WSUS console.
Computers that are not correctly patched must be fixed one by one to ensure no missing
patches were found throughout the domain.
Top test this countermeasure, we created a server that found vulnerable against patch MS08-
067. Using Metasploit framework, which is a tool for developing and executing exploit code
against a remote target machine, we launched MS08-067 exploit against this server. Since the
server was unpatched, the exploit worked. A session was created and the attacker gained
system access to the server.

Figure 62: Successful exploit using Metasploit
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 74 of 161




Aldo Elam Majiah

Next, we patched this server using MS08-067 patch from Microsoft and we tried to exploit
this server the second time. As seen in the figure below, the exploit failed, thus no session
was created.

Figure 63: Fail exploit attempt

Perform regular vulnerability assessment
Regular vulnerability scanning of the organizations network is very important as the process
checks systems for weaknesses in a network, computer OS, or application. This enables an
organization to identify vulnerable systems before these systems exploited by adversaries
such as exploits, viruses, Trojans, or other attacks.
Vulnerability scanner such as Nessus or OpenVAS will first look for IP addresses, open
ports, OS, and applications running throughout the network. Once the network is mapped and
identified, the scanner will try to determine patch completeness of the OS and then checks for
known vulnerabilities.
The organization was scanned using Nessus vulnerability scanner and the result showed a lot
of detected vulnerabilities. These vulnerabilities must be mitigated; some can be mitigated by
applying patches while others may need more drastic changes such as completely upgrading
the system. Screenshot below shows a portion vulnerability scan result of the organizations
network. The scan detected vulnerabilities and categorized them into different colors,
expressing their level of criticality.

Figure 64: Nessus scan result
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 75 of 161




Aldo Elam Majiah

These automated processes of proactively identifying security vulnerabilities must be
performed regularly to ensure there is not any high risk vulnerability exist on the network.
After performing vulnerability scan the organization will need to implement a process for
addressing the identified vulnerabilities.

Uninstall unnecessary ports and services
Only runs needed services is one of the basic strategies of attack surface reduction. There are
fewer security risks if a system turns off unnecessary functionality.
Consider two systems below which had been scanned using nmap, a security scanner
application used to discover hosts and services on that hosts. The first system (with IP
address x.x.x.x) has more surface attack area compare to the second system (y.y.y.y). The
first system has more open ports and services compare to the second. Investigation must be
performed to determine whether all the services and ports in the first system (and the second
one) are really necessary.
Nmap scan report for x.x.x.x
Host is up (0.0044s latency).
Not shown: 976 closed ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
1688/tcp open nsjtp-data
3071/tcp open csd-mgmt-port
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
3389/tcp open ms-wbt-server
5357/tcp open wsdapi
49152/tcp open unknown
49153/tcp open unknown
49154/tcp open unknown
49156/tcp open unknown
49157/tcp open unknown
49158/tcp open unknown
49167/tcp open unknown
49175/tcp open unknown
MAC Address: 5C:F3:FC:F1:68:0B (IBM)

Nmap scan report for y.y.y.y
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 76 of 161




Aldo Elam Majiah

Host is up (0.0031s latency).
Not shown: 993 filtered ports
PORT STATE SERVICE
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
1433/tcp open ms-sql-s
3389/tcp open ms-wbt-server
5357/tcp open wsdapi
MAC Address: 5C:F3:FC:F1:62:93 (IBM)

It is also worth noted that although attack surface reduction helps prevent security attacks, it
does not mitigate the amount of damage an adversaries could inflict once vulnerability is
found on the system.

Upgrade to secure protocols
During penetration testing, insecure protocols such as FTP, HTTP, and Telnet were found in
the organizations network. FTP was found to be used in 6 hosts, HTTP in 43 hosts, and
Telnet was used in 8 hosts. These protocols were insecure and adversaries may take
advantage of these protocols for example by eavesdropping or intercepting the
communications using ARP spoofing technique. If the communications to or from these hosts
are intercepted, adversaries will be able to get username and passwords used for these
services since all communications are sent in plain text. Picture below shows interception of
FTP traffic using Cain and Abel, a program which allows acquiring various kinds of
passwords by sniffing the network.

Figure 65: Cain and Abel sniffing FTP credential

Upgrade or replace these protocols to their secure counterparts, FTP can be replaced by
SFTP, HTTP can be upgraded using SSL certificate (HTTPS), and Telnet can be replaced by
SSH.

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 77 of 161




Aldo Elam Majiah

4.3 Evaluate (expert judgment)
Experts judgment is the next process in this researchs methodology. The author asked
opinions of several experts regarding artifacts that are used in this research or resulted from
it.
Experts judgment activities were conducted around June and July 2014. Six experts on either
AD or security or both fields were asked about their opinion on three artifacts. The following
artifacts are to be evaluated by expert: AD risk assessment framework and AD components,
security GPO, and threat-countermeasure pairs. The last two artifacts were the result of the
risk assessment. For details on these artifacts, please refer to appendix 7.
The expertise of the experts can be divided into two groups: experts in AD and in security
fields. Experts with ID 01, 02, and 04 are experts in AD, with additional background on risk
and audit (expert 02) and security (expert 04). Experts with ID 03, 05, and 06 are experts in
security fields. For complete references on experts profile, please refer to appendix 6.
The author presented the artifacts to the experts, explained the purpose of the assessment, and
then noted their opinions. These evaluations was conducted one by one, the author met each
of the experts in a separate time and then have an interview and discussion with them about
the artifacts.
The result of the evaluation by experts shows that AD risk assessment framework and AD
components do not change. There was an opinion from expert 03 to add one more
component, an environmental related threat component, into existing AD components. But
in the next round of evaluation, expert 04 suggested that environmental threats should not be
included in AD components.
Likewise, the security GPO also did not change. But there was a suggestion from expert 06 to
divide the security GPO into their risk level. As there was not very high countermeasure for
security GPO, it can be created as two GPO: one is security GPO for high risk
countermeasure and the other is security GPO for medium risk threats.
On the other hand, the list of threat-countermeasure pairs changed much. Six new threat-
countermeasure pairs were added by the experts and eight countermeasures were added to
thwart existing threats. Experts suggested that there were previously unlisted threats that
should be added to the threat list as they directly or indirectly threatens AD or its
environment. Similarly, eight countermeasures were suggested to be added since the current
countermeasures might not be sufficient to thwart the related threats.

4.4 Observation
It has been observed from experts opinion that AD risk assessment framework, AD
components, and security GPO do not change as threat-countermeasure pairs. Threat and
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 78 of 161




Aldo Elam Majiah

countermeasure pair changes significantly in accordance to the experts expertise. Much of
the new threats, and their countermeasures, are revealed during expert judgment discussions.
This could be because the natures of threats of a system are ever increasing, and so is the
knowledge to identify these threats and how to create countermeasures for them.
Risk assessment framework and AD components used as theoretical framework in this
research is not changed, as shown in the figure 67 below. There are 7 steps in risk assessment
framework. The AD risk assessment framework steps are: AD system characterization, threat
sources and events identification, identification of vulnerability, determination of likelihood
of occurrence, determination of impact magnitude, risk determination, and the last step is
countermeasure recommendation.

Figure 66: Final AD risk assessment framework

These AD risk assessment steps are to be performed in 6 AD components. These components
are AD design & boundary, AD management, policy implementation, security of AD
computer members, security of network, and security of DC.

Figure 67: Final AD components
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 79 of 161




Aldo Elam Majiah

The assessment on the organizations AD environment shows the following results of risk
level: 5 very high, 21 high, 79 moderate, 86 low, and 30 very low risks.

Figure 68: Risk assessment results (moderate risk level and up)

Out of these risks results, only risk with moderate level and up are treated. Low and very low
risks are considered accepted. The organization currently does not have any standard for risk
assessment, so it is assumed that the risk appetite and culture of the organization are already
integrated in the risk calculation process.
The countermeasure recommendation results have two forms: a set of security GPO
countermeasures and a list of threat-countermeasure pair as shown in subchapter 3.3.1.
During expert judgment, the security GPO is not modified by experts. There is only a note
suggesting that these GPO may not be suitable for all AD environments.
GPO countermeasures implementation can be categorized into two risk levels: high and
medium. High risk GPO countermeasures are for securing high risk threats, and medium
GPO is for medium risk threats. The implementation of high risk level GPOs consists of a set
of settings for password policies, limiting access for accounts with blank passwords, and
disabling storage of LAN Manager password hash.
5
21
79
0
10
20
30
40
50
60
70
80
90
VERY HIGH HIGH MODERATE
Risk assessment results
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 80 of 161




Aldo Elam Majiah


Figure 69: Implementation of high risk GPO countermeasures

While medium GPO countermeasures consists of implementation of account lockout policies,
Kerberos policies, audit policies, several user rights assignments, and most of security
options.

Figure 70: Implementation of medium risk GPO countermeasures (1)
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 81 of 161




Aldo Elam Majiah



Figure 71: Implementation of medium risk GPO countermeasures (2)


Figure 72: Implementation of medium risk GPO countermeasures (3)

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 82 of 161




Aldo Elam Majiah

The threat and countermeasure pair list, on the other hand, is modified based on experts
knowledge. The final countermeasures for the organizations AD environment are shown in
the following table. Countermeasures with Orange background are medium risk-level
countermeasures, bright red background categorize high risk countermeasures, and dark red
background shows they were countermeasures for very high risk threats. Countermeasures
without background color are the ones found during discussions with the experts. These
countermeasures are also categorized further in accordance to people, process, and
technology.
Table 11: Final countermeasures and their categories
Countermeasure
Categories
People Process Technology
Create documentation on AD; the document should include deployment, configuration,
structure, and policy guide. And it should be approved by management and controlled.





Upgrade domain and forest functional level to highest level possible to access more
secure AD domain configuration.






Create secondary domain controller.






Create and utilize computer-based OU in accordance to their computer functions, for
example server OU, teachers' workstation OU, library computers OU, etc.





Limit & control the use of high privilege domain accounts.






Utilize the use of restricted group to groups / accounts and minimize the use of domain
admins groups for performing daily tasks






Create a separate accounts to be used by administrators. One for doing daily, office-
related, tasks and the other one is for managing domain.






Implement a more secure password policy for local users.






Implement a more secure password policy for domain users.






Implementation of dual custody





Implement more secure account lockout policy.






Utilize log monitoring software and perform regular check on AD logs, specially on logon
attempts log events and security event logs.




Enable DNS logging






Perform regular backup on AD, create documents on AD backup, and test the backup
result regularly.




Implement an automatic patch management system. Monitor the patch management
system regularly to ensure all domain computers are patched.







Assign and train administrators to monitor and elimnate incomplete patches





Perform regular vulnerability assessment in accordance to organization's policy (e.g.
once a year) to identify unnecessary ports, protocols, services.






Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 83 of 161




Aldo Elam Majiah

Countermeasure
Categories
People Process Technology
Implement IPS for detecting network attack.






Static ARP implementation






Impement DHCP snooping






Securing switch physical access





Upgrade to secure protocols.






Create a policy and standard about which applications are permitted on workstations and
servers (application whitelist).






Implement network traffic whitelisting using application-based firewall.






Minimizing surface attack






Uninstall unnecessary ports and services.






Create a policy / standard for basic security hardening for workstations and servers
deployment. Implement and control the policy.







Ensure that anti-virus were deployed correctly to all domain computers.






Ensure anti-virus pattern are updated in all domain computers






Disable booting from portable / removeable media from BIOS. Protect BIOS with
password.






Enabled host-based firewall implementation via GPO to ensure uniform implementation
of firewall throughout the domain.







Conduct users' awareness program or training on IT security.





Create and implement classifcation of information





Create a well segregated network. Server and workstations should have separated VLAN.
Management network and out of band VLAN should only be accessible for the
administrators.




Enable biometric-based locks and monitor in/out logs.




Encrypt sensitive information.




Implement a correct audit policy to help in investigating a security incidents case.Which
part of audit policy that should be enabled usually depends on the organization's policy.
At least audit of success and failure of authentication of account logon events must be
enabled.




Develop IT security policy which include acceptable use of workstations, internet, email,
etc.





Develop SDLC policy and intergrate security concerns in SDLC.





Implement DLP solution




Screensaver implemented, protected with password


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 84 of 161




Aldo Elam Majiah

Out of all 41 countermeasures listed in table 11, 15 countermeasures are technical in nature
and they have been tested in prototyping phase to see if they are implementable and effective.
The prototyping phase is conducted using real replica of the organizations AD in a virtual
environment. The rest of the countermeasures cannot be tested in a short time or by using
virtual environment. Countermeasures tested in prototyping phases are:
1. Disable booting from alternative OS
2. Upgrade to higher domain and forest functional level
3. Create secondary DC
4. Create computer-based OU
5. Limit & control high privilege domain accounts
6. Utilize the use of restricted groups
7. Separate account for administrators
8. Implement secure password policies
9. Implement secure account lockout policies
10. Perform regular AD backup
11. Automatic patch management system
12. Perform regular vulnerability assessment
13. Uninstall unnecessary ports and services
14. Create AD documentation
15. Upgrade to secure protocols
Countermeasures resulted from risk assessment process are tailored specifically for AD
implementation in the assessed organization. These countermeasures may not be suitable if
they are used in other organizations AD since result of risk assessment will be different from
one AD to another. This is the actual strong point of countermeasures resulted from this
framework, that they are specifically designed for a particular environment.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 85 of 161




Aldo Elam Majiah

CHAPTER 5 CONCLUSION
5.1 Conclusion
This master thesis focuses to find security countermeasure for AD, a ubiquitous system found
in almost all enterprises. In order to does this, this thesis create a risk assessment approach to
find countermeasure for AD threats.
Countermeasures resulted from the risk assessment process are specifically tailored for the
AD environment of the organization being assessed. This is the actual strong point of
countermeasures resulted from this framework, that they are specifically designed for a
particular environment. There are many guidelines, books, or best practice for securing AD.
But these books, guidelines, or best practice may not be suitable for AD implementation in an
organization since not all organizations suffer from the same threats. Using AD risk
framework as described in this research, not only an organization will be able to find out
which countermeasures should be implemented, but also it will also know which of them
should be implemented first since these countermeasures are categorized into their risk level.
The evaluation from experts shows that AD risk framework and AD components do not
change, which means it could be used to evaluate other AD environment. Nevertheless, the
list of threat events and their countermeasures are changing and evolving. Almost all of the
experts have new knowledge on AD related threats and their countermeasures, which are not
listed yet in the threat event list. This may be caused by the fact that threats are always
increasing, and so are the knowledge to countermeasure them.
Therefore, within this master thesis, it was shown that the problem of insecure
implementation of AD and its environment can be addressed using risk assessment approach.
Specific threats on an organizations AD and the recommended countermeasures were
identified in well-structured processes, which can be performed in accordance to the
developed framework.

5.2 Recommendations
It was recommended for the organization where AD implementation being assessed to
implement countermeasures as soon as possible, especially countermeasures for high and
very high risks.
For organizations that are planning to assess their AD security using the framework used in
this research, it is recommended to perform the risk assessment processes by experienced
personnel or consultants that have exposures in both Active Directory and security field. The
result of a risk assessment may differ from one another depends on the knowledge on the
ones who perform it.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 86 of 161




Aldo Elam Majiah

For AD security administrators who are managing AD daily, cautions must be used when
implementing a security GPO. It is best to test first a security GPO in a group of users or
computers before widely implementing it in a domain.

5.3 Future works
Evaluation by experts showed that there were still unlisted threats and countermeasures. This
is expected since the nature of threats and countermeasures are ever evolving. New threats to
AD or other systems are generated in daily basis but so are the technology and method to
counter these threats. This fact could be the limitation of this research. In a sense, the threat
list is only valid if it is updated regularly. If it is not regularly updated then the list could not
reflect newer threats or, on the contrary, the threats are becoming obsolete.
List of threat events (appendix 3) can be improved by adding new threats or deleting
irrelevant old threats from the list. This threats list is one of the strength provided by this
framework. Hence, an updated list of threat events could prove extremely useful in the search
of finding countermeasures for AD threats.
One way to improve the list of threats, and the countermeasures associated with it, is to
perform expert crowdsourcing on the AD threat list. Using expert crowdsourcing, a more
comprehensive list of threats or countermeasures could be acquired by soliciting
contributions from a large group of experts, especially from an online community. The idea
of expert crowdsourcing on a particular topic is not a new idea. For example, the MITRE
corporation (http://www.mitre.org) has been using expert crowdsourcing for developing its
CWE (common weakness enumeration), a comprehensive list of weakness on web
applications.
The future work encompasses further use of the developed framework for other AD systems.
Testing similar approach on other AD environment could prove or even enhanced the AD
risk framework, AD components, key activities, and the threat events list. Directly
implementing the result of the assessment in an AD environment and then re-do the
penetration testing processes could also prove the effectiveness of the countermeasures.
The integration of AD risk assessment concept into organization or enterprise AD
environment should be performed to mitigate the ever increasing AD-related security threats.
Therefore, in the dynamic AD environments of the future, the concept of performing regular
AD risk assessment seems to be very perspective.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 87 of 161




Aldo Elam Majiah

GLOSSARY

ACL
Access control list.

AD
Active Directory.

ADDT
Active directory domains and trusts.

ADUC
Active directory users and computers.

AP
Access point (for wireless connection).

ARP
Address Resolution Protocol.

DC
Domain controller (server for Active Directory).

DDoS
Distributed denial of service.

DLP
Data loss prevention.

DNS
Domain Name System.

Domain
Hierarchy of objects in a data partition that is replicated between one or more domain
controllers.

DoS
Denial of service.

DS
Design Science.

DSRP
Design Science Research Process.

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 88 of 161




Aldo Elam Majiah

FAIR
Factor Analysis for Information Risk.

Forest
Collection of data partitions and domains.

FSMO
Flexible Single Master Operation Roles.

GPO
Group Policy Objects in Active Directory are a set of defined rules for settings about the user
environment or the operating environment for a particular PC.

IE
Internet Explorer.

IS
Information system.

LDAP
Lightweight Directory Access Protocol.

OS
Operating system (Windows, Linux, etc.).

OU
Organizational Unit. The primary type of container that is created to house objects is called
an organizational unit.

MITM
Man in the middle.

Namespace
A defined area where standardized names can be used to symbolically represent some type
of information or data (such as an IP address) and that can be resolved to the object itself.
PDC
Primary domain controller.

PIC
Person in charge (of the system).

RID
Relative identification.


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 89 of 161




Aldo Elam Majiah

Sites
AD representation of network location. Sites give a very unique and well-designed approach
to separate specific locations within your Active Directory.

Trust
An agreement between two domains or forests to allow security principals (i.e., users,
groups, and computers) from one domain or forest to access resources in the other domain
or forest.

VPN
Virtual private network.

WINS
Windows Internet Name Service.

WPAD
Web Proxy Autodiscovery Protocol.

WSUS
Windows Server Update Services



Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 90 of 161




Aldo Elam Majiah

REFERENCES

Alan R. Hevner, e. a., 2004. Design Science in Information System Research, s.l.: MIS
Quarterly.
Ammann, R. a. P., 2000. Using Model Checking to Analyze Network Vulnerabilities, s.l.: s.n.
Asha. N, e. a., 2012. Preventing SQL Injection Attacks, s.l.: International Journal of
Computer Applications.
Barnard, e. a., 2006. Why It Is Important to Audit Your Active Directory?, s.l.: Genesis
RKeyTec.
Bertino Bruschi, e. a., 2005. THREAT MODELLING FOR SQL SERVERS, Designing a
Secure Database in a Web Application, West Lafayette, IN, USA: CERIAS, Purdue
University.
Beth Sheresh, D. S., 2002. Understanding Directory Services, s.l.: System Research
Corporation.
Brian Desmond, e. a., 2013. Active Directory, s.l.: O'Reilly.
Center for Strategic and International Studies, 2013. Critical Controls for Effective Cyber
Defense, s.l.: SANS.
Chadwick, D., 2005. Threat Modelling for Active Directory, s.l.: Communications and
Multimedia Security , IFIP The International Federation for Information Processing
Volume 175, 2005, pp 173-182 .
Chia-jung Tsui, e. a., 2010. Building an IT Taxonomy with Co-occurrence Analysis,
Hierarchical Clustering, and Multidimensional Scaling, s.l.: University of Marlyland,
iConference.
Common Criteria for Information Technology Security Evaluation, 2012. Part 3: Security
assurance components, s.l.: s.n.
D'Arcy, J. P., 2007. The Misuse of Information System: The Impact of Security
Countermeasures, s.l.: LFB Scholarly.
Defence Signals Directorate, 2012. Strategies to Mitigate Targeted Cyber Intrusions, s.l.:
Australian Government Department of Defence.
Eichstdt, R. G. a. H., 2005. THREAT MODELLING FOR ASP.NET, Designing Secure
Applications, Ilmenau: University of Technology, Ilmenau.
Farahmand, F., 2004. Developing a Risk Management System for Information Systems
Security Incidents, s.l.: Georgia Institute of Technology.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 91 of 161




Aldo Elam Majiah

Ferrell, 1994. Discrete subjective probabilities and decision analysis: elicitation, calibration
and combination, New York: Wiley.
Hale, J. D. a. J., 2004. A Systematic Approach to Multi-Stage Network Attack Analysis, s.l.:
University of Tulsa.
Hideaki Takeda, e. a., 1990. Modelling Design Process, s.l.: AI Magazine.
Huang, Y., 2004. SCITDNS: Critical Infrastructure Protection through Secure DNS Server
Dynamic Updates, s.l.: Trusted Internet Workshop Conference.
Ihor Kuz, e. a., 2002. The Globe Infrastructure Directory Service, s.l.: Computer
Communications, Elsevier.
InformationWeek Analytics, 2011. 2011 strategic security survey, s.l.: s.n.
International Telecommunication Union, 2003. Security in Telecommunications and
Information Technology, s.l.: ITU.
ISACA, 2009. THE RISK IT PRACTITIONER GUIDE, Rolling Meadows, IL: ISACA.
ISACA, 2010. Windows Active Directory Audit/Assurance Program, s.l.: ISACA.
IT Security Firm X, 2013. Penetration testing report compendium, s.l.: s.n.
Janes, P., 2012. People, Process, and Technologies Impact on Information Data Loss, s.l.:
SANS Institute.
Ken Peffers, e. a., 2006. THE DESIGN SCIENCE RESEARCH PROCESS: A MODEL FOR
PRODUCING AND PRESENTING INFORMATION SYSTEMS RESEARCH, Claremont: s.n.
Kocis, K., 2001. Microsoft Active Directory Administration, Indiana: Sams Publishing.
Konstantinos Xynos, e. a., 2010. PENETRATION TESTING AND VULNERABILITY
ASSESSMENTS: A PROFESSIONAL APPROACH, s.l.: International Cyber Resilience
conference.
L. A. Gordon, e. a., 2006. CSI/FBI Computer Crime and Security Survey, s.l.: 11th Annual
CSI/FBI Computer Crime and Security Survey.
Lenaghan, e. a., 2007. Managing Security Threats and Vulnerabilities for Small to Medium
Enterprises, s.l.: Kingston University, IEEE International Conference on Intelligence and
Security Informatics.
Majiah, A. E., 2014. Vulnerbility scan and penetration testing document of (undisclosed
organization name), Jakarta: s.n.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 92 of 161




Aldo Elam Majiah

Manadhata, P. K. a. J. M. W., 2011. An Attack Surface Metric, s.l.: IEEE TRANSACTIONS
ON SOFTWARE ENGINEERING.
Mark RM Talabis, J. L. M., 2013. Information Security Risk Assessment Toolkit, s.l.:
Syngress.
Mary A. Meyer, J. M. B., 2001. Eliciting and Analyzing Expert Judgment, s.l.: s.n.
Michael A. Davis, e. a., 2010. Hacking Exposed: Malware and Rootkits, s.l.: McGraw-Hill.
Michael T. Simpsons, e. a., 2011. Hands-on Ethical Hacking and Network Defense, 2nd ed.,
s.l.: Course Technology.
Microsoft, 2006. Centralized Management Component Overview, s.l.: Microsoft.
Microsoft, 2010. Technet. [Online]
Available at: http://technet.microsoft.com/en-us/library/cc787290(v=ws.10).aspx
Microsoft, 2013. Securing Active Directory: An Overview of Best Practices, s.l.: Microsoft.
Microsoft, 2014. [Online]
Available at: http://technet.microsoft.com/en-us/library/hh852345.aspx
NIST, 2002. Special Publication 800-30: Risk Management Guide for Information
Technology Systems, s.l.: National Institute of Standards and Technology.
NIST, 2008. Special Publication 800-123 Guide to General Server Security, s.l.: NIST.
NIST, 2012. NIST Special Publication 800-30 Revision 1, Gaithersburg: National Institute of
Standards and Technology.
OHagan, e. a., 2006. Uncertain judgments: eliciting expert probabilities, West Sussex: John
Wiley.
Osterman Research, 2010. An Osterman Research survey report, s.l.: s.n.
Oxford University Press, 2010. New Oxford American Dictionary, s.l.: s.n.
Paul Ammann, e. a., 2005. A HostBased Approach to Network Attack Chaining Analysis,
s.l.: roceedings of the 21st Annual Computer Security Applications Conference.
Richard A. Caralli, e. a., 2007. Introducing OCTAVE Allegro: Improving the Information
Security Risk Assessment Process, s.l.: CarnegieMellon.
Robbie Allen, e. a., 2003. Active Directory, 2nd Edition., s.l.: O'Reilly.
Rommel, F., 2008. Active Directory Disaster Recovery, Birmingham: Packt Publishing.
Sakari Kouti, M. S., 2004. Inside Active Directory, 2nd ed., s.l.: Addison Wesley.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 93 of 161




Aldo Elam Majiah

Salvatore T. March, G. F. S., 1995. Design and Natural Science Research on Information
Technology, s.l.: Elsevier.
Sandberg, S. E., 2013. Endpoint Security in the Modern Enterprise, s.l.: NTNU - Norwegian
University of Science and Technology.
Shostack, A., 2014. Threat Modelling: Designing for Security, Indianapolis: John Wiley &
Sons.
Straub, D. W., 1986. Deterring computer abuse: The effectiveness of deterrent
countermeasures in the computer security environment, s.l.: Indiana University.
Straub, D. W., 1990. Effective IS security: An empirical study. Information, s.l.: s.n.
Tankard, C., 2012. Taking the management pain out of Active Directory, s.l.: Network
Security.
The Defence Signals Directorate Australia, 2012. Top 4 Mitigations Against Cyber Intrusion:
An Implementation Guide for Project Managers, s.l.: DSD Australia.
Timothy A. Howes, e. a., 2003. Understanding and Deploying LDAP Directory Services,
Second Edition, s.l.: Addison Wesley.
Walls, J. G. e. a., 1992. Building an Information System Design, s.l.: Information Systems
Research.
Wilkins, M., 2001. Administering Active Directory, s.l.: McGraw-Hill.
Yih Huang, e. a., 2006. Closing Cluster Attack Windows Through Server Redundancy and
Rotations, Fairfax: Department of Computer Science and Center for Image Analysis.


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 94 of 161




Aldo Elam Majiah

APPENDIX
Appendix 1: AD Characterization Assessment (original forms)

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 95 of 161




Aldo Elam Majiah

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 96 of 161




Aldo Elam Majiah

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 97 of 161




Aldo Elam Majiah

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 98 of 161




Aldo Elam Majiah

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 99 of 161




Aldo Elam Majiah

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 100 of 161




Aldo Elam Majiah

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 101 of 161




Aldo Elam Majiah



Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 102 of 161




Aldo Elam Majiah

Appendix 2: AD Characterization Assessment (printed)
AD characterization questions and answers
AD design & boundary:
What is the forest and domain structure?
It is a single domain and single forest. There is only one domain and there are no trusts to other domain.
Please create / obtain a hierarchal diagram representation of the AD structure, starting with the forest down to domain.
There is only one forest, one domain:


Is there any forest or domain trust relationship(s)?
No, there is not. This is a single domain, single forest, without any relationship with other domain.

If there are trust relationships, are external trusts permitted only with prior authorization?
There is not any trust relationship. The organization only has one AD.


Are there appropriate administrative controls to prevent unauthorized granting of trusts?
No, trusts are available because there is no other domain. Trust can only be made with higher privilege domain admin /
enterprise admin / schema admin.

Do you have AD design documentation or AD policy documentation?
Currently, the organization does not have any AD documentation or policy.

If there are more than one forest or domain structures; does the structure provides for a separation between service
administrators? (considering administrative and security boundaries between forest/domain administrators)
There is only one AD structure. Administrators are only managing this xxxjkt.com domain.
AD management
What is the domain and forest functional level?
Domain functional level: Windows server 2003.
Forest functional level: Windows server 2003.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 103 of 161




Aldo Elam Majiah

AD characterization questions and answers
Operating system on the DC: Windows server 2008.

Which server(s) hold FSMO roles?
There is only one AD server. This server holds all five FSMO roles.
Hostname: xxx-xxxxment
IP: xxx.xxx.0.1

Please provide the domain tree structure:


Has OU deployment already aligned with organizations structure?
OU is divided into three roles of users: teachers, staff, and students.
There is not any computer OU. Computer objects OU should be divided into at least servers and workstations, etc.

Has security group deployment already aligned with organizations needs?
Security groups are not deployed effectively. There were only several security groups: teachers (with 2 members), it (6
members), and student class security groups.

Who are responsible for AD? (considering personnel capabilities, workload, skills, and separation of duties)
PIC responsible for AD is: Mr. H. He is also responsible for helpdesk daily job. All the administrators workload mainly comprise of
helpdesk duties. No personnel has Microsoft certifications.

Please provide existing AD documentations (policies, logs, previous audit, etc):
There is not any yet. The organization has only helpdesk log.

Are there controls for high privilege accounts groups (for example Domain Admins, Enterprise Admins, and Schema Admins
groups)?
No control exists yet. Personnel can create high privilege accounts on need basis. If they need it, they will create it.

How they are controlled?
The organization does not have any policy or change management on controlling high privilege accounts yet.

Is there delegation of tasks to groups/accounts?
Delegation wizard has never been used to delegate tasks to groups/accounts.

Is there a separation of daily accounts and administrative accounts?
No, there is not. High privilege accounts such as domain admins are also used for daily login to workstations and for doing daily
tasks.

Are there accounts used for service, applications, or other accounts which passwords are rarely changed?
Yes, install support accounts (with domain admin privilege) are used to install software in workstations. Furthermore, local
administrator passwords are the same throughout the domain.

Does the organization use restricted groups feature? What for?
No, the organization does not use restricted group features.

Is there a change management for AD?
No, there is no change management for AD.

How do you review AD log monitoring capabilities? Do you use automated log reviewing tools?
The AD logs are not monitored, and the organization does not use automated log reviewing tools yet.

Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 104 of 161




Aldo Elam Majiah

AD characterization questions and answers
What is the OS of the DC? Determine if AD functional level (forest or domain) is already the highest for DCs operating system.
The OS of the DC is Windows server 2008. The OS is higher than AD forest and domain functional level, which is 2003.

Is there a secondary DC for each site?
No, there is not. There is only one site: default-first-site-name and there is only one DC xxx-xxxment.xxxjkt.com


Does the organization backup the AD? Is there a backup procedure for AD?
No backup yet, and there is not any backup procedures for AD either.

Is there a periodic restore testing procedures for AD backup? Is the procedure implemented correctly?
No backup restore testing for AD either.

Policy implementation
Can GPO be deployed and implemented easily utilizing existing OU deployment?
It will be hard to deploy GPO based on computers object because there is not OU for computer objects. All computer objects are
in default computers OU, which cannot be linked to a GPO.

Review of security settings policy implementation: Account policies (password policies, account lockout policy, Kerberos
policy).
Password policy, Account lockout policy, and Kerberos policy:


Review of security settings policy implementation: audit policy.
Audit policy is not implemented.

Review of security settings policy implementation: user rights assignments.
User rights assignments policies are not implemented.

Review of security settings policy implementation: security options.
Security options policies are also not implemented.

Review of security settings policy implementation: event log.
Event log policies are also not configured.

Security of AD computer members
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 105 of 161




Aldo Elam Majiah

AD characterization questions and answers
Is there patch management system (patch for OS and applications)? Are patches for OS and applications set to automatically
update?
No WSUS sever available but all computers member are in default set to automatically update, yet this settings is not enforced
consistently using GPO.

Does the organization have a list of application whitelist (permitted applications) to be deployed in servers and workstations?
There is not application whitelist. There is not document showing application whitelisting either.

How can the use of administrative privilege be controlled?
Local administrators passwords are only known by IT staff. But there is no control or documents describing who can use the
administrative privileges locally or domain wide.

Are there secure configurations or procedures for deploying servers and workstations? (for example: disabling unrequired
applications or services, patching before deploying servers or workstations).
Currently there is not procedure for deploying or configuring servers or workstations.
Are anti-virus and anti-malware software correctly deployed to all servers and workstations? (check if antivirus software has
been installed, determine if antivirus software can be disabled or removed, check if the signature files are updated regularly).
Most of workstations and servers have their anti-virus deployed correctly. The anti-virus is updated regularly and cannot be
disabled without knowing the password.
Is there a control or procedures for using removable and portable media?
Currently there is not any control, technically or procedurally, for the use of USB or portable CD/DVD media.

Is there a continue vulnerability scanning processes for all AD computer members?
No, currently the organization does not have vulnerability scanning process, either one time or regularly, for AD computer
members.

Are data (servers/applications and users data) backed up?
Only staff and teachers data are backed up in NAS. The backup was sent regularly to holding company. Students data and
servers data are not backed up.

Are default Windows firewall configured for each servers and workstations?
No, default Windows firewall are not configured via GPO. Several workstations and servers have their firewall up, but most of the
computers do not have their firewalls configured.

Does the organization regularly conduct users education program or security awareness trainings?
No, there is not security awareness or training for users.

Identify whether LanMan is still used on servers/ workstations.
Yes, LanMan is still used on servers/workstations. No GPO deployed for disable the use of LanMan.

Identify whether there are security-related incidents in helpdesk logs.
Users are sometimes allowed to login locally if the cannot log into their computers.
Security of network
Is there a separate VLAN for users connected to wireless AP? How is the network segregation for this wireless connection?
No, there is not a separate network for wireless users. Users connected to wireless will directly join to the default-first-name-site.
They will part of subnet xxx.xxx.0.0/255.255.255.248.0

Review whether there are secure network configurations documents for network devices (such as firewalls, routers, and
switches).
There are not any network configuration documents for network devices. The switch/router in the organization is owned by ISP
service provider, not by the organization.

Are network ports, protocols, and services are limited and controlled? Check this using port enumeration technique.
There are insecure network protocols in used in the organization.
FTP:
xxx.xxx.0.100, xxx.xxx.0.220, xxx.xxx.0.221, xxx.xxx.0.222, xxx.xxx.0.254, xxx.xxx.2.254
HTTP:
xxx.xxx.0.1, xxx.xxx.0.5, xxx.xxx.0.17, xxx.xxx.0.22, xxx.xxx.0.90, xxx.xxx.0.100, xxx.xxx.0.107, xxx.xxx.0.118, xxx.xxx.0.12,
xxx.xxx.0.151, xxx.xxx.0.156, xxx.xxx.0.157, xxx.xxx.0.160, xxx.xxx.0.169, xxx.xxx.0.173, xxx.xxx.,.175, xxx.xxx.0.178, xxx.xxx.0.220,
xxx.xxx.0.221, xxx.xxx.0.222, xxx.xxx.0.240, xxx.xxx.0.241, 192,168.0.242, xxx.xxx.0.243, xxx.xxx.0.244, xxx.xxx.0.245,
xxx.xxx.0.247, xxx.xxx.0.254, xxx.xxx.1.60, xxx.xxx.1.99, xxx.xxx.1.161, xxx.xxx.2.250, xxx.xxx.2.252, xxx.xxx.2.254, xxx.xxx.3.33,
xxx.xxx.3.5, xxx.xxx.3.81, xxx.xxx.3.119, xxx.xxx.5.112, xxx.xxx.6.11, xxx.xxx.6.21, xxx.xxx.6.74, xxx.xxx.7.49
Telnet:
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 106 of 161




Aldo Elam Majiah

AD characterization questions and answers
xxx.xxx.0.220, xxx.xxx.0.221, xxx.xxx.0.222, xxx.xxx.0.241, xxx.xxx.0.242, xxx.xxx.0.244, xxx.xxx.0.254, xxx.xxx.2.254

Are there separate VLANs? How are these VLANs different from each other? Identify network segmentation / segregation.
There is only one big VLAN: xxx.xxx.0.0/255.255.248.0. Currently there is no network segmentation; servers, users, teachers,
students, and guests are all connected to this one VLAN.

Does the organization use network based intrusion detection / prevention system?
No, the organization does not have IDS or IPS.

Does the organization use web proxy for users Internet connection? If yes, is there a use of website blacklisting in the proxy?
The organization does not have a proxy that can function as website blacklisting device. The proxy used in the organization is a
router and is connected directly to Internet.

Are cabling rooms locked with limited access and the accesses are logged?
Cabling rooms are the same with server room. The room uses access control in the form of a key, the key is managed by security
and IT team.

Does the organization use separate and dedicated VLAN for management ports of domain controllers and servers (RDP, SSH)?
If yes, is this dedicated management network segmented from other networks and only admin workstations can connect to
them?
No, the organization does not have a dedicated VLAN for management ports. All users can connect directly to servers
management ports using for example, SSH, RDP or Telnet.

Security of DC
Do DCs have already the latest security patches / service packs?
Yes, the DC has the latest security patches and service packs as shown in below screenshot.


Are there secure configuration documentations or procedures for deploying DC?
No, currently the organization does not have secure documentations or procedures for deploying DC.

Are all DCs placed in a secure physical facility (for example; a fingerprint-protected datacenter)?
DC is placed in the server room (the same as cabling room). The room is not protected by biometric device but by a key. Security
and IT department both have access to the key.

Are anti-virus and anti-malware software correctly deployed on DC? (Check if antivirus software has been installed, determine
if antivirus software can be disabled or removed, check if the signature files are updated regularly).
Yes, the DC is using anti-virus. The anti-virus is updated regularly and it cannot be disabled without a password.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 107 of 161




Aldo Elam Majiah

AD characterization questions and answers
Does the DC runs only essential services or features?
No, the DC has many applications installed such as firebird database, file server services, and web server. The DC also functions as
DNS and DHCP server.

Determine whether only authorized personnel are allowed to access DC physically.
The key to server room, where the DC is placed, can be accessed by IT and security department.

Does the DC use dual power supply input? One from power line and the other is issuing a backup power supply (UPS)?
Yes, the DC is using UPS (uninterruptable power supply).

Can the DC be booted using alternative OS?
Yes, the DC can be booted via USB ports or DVD portable media. BIOS is also not protected by password.

Does the DC use a secure out-of-band management network? (for example; ILO for HP servers)
No, the DC does not have out of band management network.



Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 108 of 161




Aldo Elam Majiah

Appendix 3: List of Threat Events and Description
AD
Characterization
Threat
ID Threat events Threat description
AD design & boundary
Identify forest and
domain structure (for
example: the
implemented AD is single
forest, multiple domains).
T1
Forest and domain
structure threats
Incorrect, hidden, forgotten, or unmanaged forest and domain structures
may expose other domain/structure to threats. For example parent - child
domain structure means the parent domain normally has full access to
child domain. There could also some hidden, forgotten, or unmanaged
domain that has access to other domains. Attacker could target these
domain/forest to get into main domain.
Obtain a hierarchal
diagram representation of
the AD structure, starting
with the forest down to
domain.
T2
Forest and domain
structure threats
Incorrect, hidden, forgotten, or unmanaged forest and domain structures
may expose other domain/structure to threats. For example parent - child
domain structure means the parent domain normally has full access to
child domain. There could also some hidden, forgotten, or unmanaged
domain that has access to other domains. Attacker could target these
domain/forest to get into main domain.
Review of forest or
domain trust
relationship(s) and
determine that external
trusts are permitted only
with prior authorization.
T3 Trust authorization threats
Attacker may create a new trust if trust authorization is not controlled or
trust can be created without prior authorization.
Determine whether there
are appropriate
administrative controls to
prevent unauthorized
granting of trusts.
T4 Trust authorization threats
Attacker may create a new trust if trust authorization is not controlled or
trust can be created without prior authorization.
Review AD design
documentation.
T5
AD structure and design
modification threat
Attacker may modify the structure or design of an AD undetected if there
are not proper documentations for AD.
Determine if the forest or
domain structure
provides for a separation
between service
administrators,
considering
administrative and
security boundaries
between forest/domain
administrators.

T6
Administrative boundary
threat
Attacker (or administrator) could potentially damage AD domain
(intentionally or unintentionally) if there are segregation of duties between
each domain/forest administrators.
AD management
Identify domain and
forest functional level.
T7
Lower functional level than
OS
Domain or forest functional level might be lower than the OS of the
DC(s). Functional level should be upgraded to the highest possible level
whenever possible. Higher domain/forest functional level provides better
security.
Identify servers holding
FSMO roles.
T8 Availability of FSMO roles
The following FSMO roles should be available in a high availability for
each domain: PDC emulator, RID master, Infrastructure master. The
following FSMO roles should be available in a high availability for each
forest: Schema master, Domain naming master.
Identify domain tree
structure.
T9
AD structure and design
modification threat
Attacker may modify the structure or design of an AD undetected if there
are not proper documentations for AD
Determine if OU
deployment has already
aligned with
organizations structure.
T10
Alignment between
business and AD structure
Structure of AD should be aligned with business to ease deployment of
policies, software, or other related AD management issues. For example
usually users and computers are separated due to the nature of GPO
that can be deployed for either users or computers or both. OUs are
usually represent the name of departments in the organization to ease
deployment of specific software to specific departments.
Determine if security
group deployment has
already aligned with
organizations needs.
T11
Alignment between
business and AD groups
Security groups and distribution groups should be deployed in
accordance to organization's structure. For example, there should be a
helpdesk security group that has access to all users' workstations.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 109 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description
Identify the organizations
personnel responsible for
AD, considering
personnel capabilities,
workload, skills, and
separation of duties.
T12 AD PIC capabilities threats
PIC for AD should be trusted, able, and have time to manage AD.
Identifying personnel responsible for AD is important to avoid
unauthorized management access, accidental modification to objects,
and poorly managed AD.
Review existing AD
documentations (policies,
logs, previous audit, etc).
T13 Proper documentation
There should be documents reviewing AD policies and procedures.
Undocumented AD system (environment) could present various threats
as there is not any standard for managing AD. This could lead to
insecure modification of AD structure, objects, or environment.
Determine if high
privilege accounts groups
are controlled (for
example Domain Admins,
Enterprise Admins, and
Schema Admins groups).
T14
High privilege account
threat
High privilege accounts (domain admins, enterprise admins, schema
admins, restricted groups that has access to workstations, etc.) must be
limited, controlled, and logged. If an attacker could gain access as a
domain admin, for example, he/she could control the entire computers
and data in the AD. Restricted groups/accounts should also be identified
to detect improper use of delegation task.
Review delegation of
tasks to groups/accounts.
T15
High privilege account
threat
High privilege accounts (domain admins, enterprise admins, schema
admins, restricted groups that has access to workstations, etc) must be
limited, controlled, and logged. If an attacker could gain access as a
domain admin, for example, he/she could control the entire computers
and data in the AD. Restricted groups/accounts should also be identify to
detect improper use of delegation task.
Review if separation of
daily accounts and
administrative accounts
exists.
T16 Account segregation threat
Administrators or other holder of high privilege accounts should separate
their daily account and the high privilege account. This separation is
necessary to ensure the administrators do not perform daily tasks
(browsing, doing office works) with their high privilege accounts.
Whenever the administrators need to do AD management tasks, they can
use "run as" feature. This separation of daily account and high privilege
account for administrators could also minimize escalation privilege from
high privilege account.
Identify accounts used for
service, applications, or
other accounts which
passwords are rarely
changed.
T17
Rarely changed password
threat
Some accounts used in service or application uses rarely changed, or
even never changed, passwords. Attacker could try to brute force all
accounts with a known rarely changed passwords and find all the
credentials.
Identify restricted groups. T18
High privilege account
threat
High privilege accounts (domain admins, enterprise admins, schema
admins, restricted groups that has access to workstations, etc) must be
limited, controlled, and logged. If an attacker could gain access as a
domain admin, for example, he/she could control the entire computers
and data in the AD. Restricted groups/accounts should also be identify to
detect improper use of delegation task.
Identify existing change
management for AD.
T19 AD design modification
Attacker may modify the structure or design of an AD undetected if there
are not proper documentations for AD
Review AD log
monitoring capabilities.
T20 Improper log monitoring
Improper log monitoring could lead to various threats such as undetected
escalation of privilege, undetected login attempt from high privilege
accounts, and undetected unauthorized login into DC(s).
Determine if AD
functional level (forest or
domain) is already the
highest for DCs
operating system.
T21
Lower functional level than
OS
Domain or forest functional level might be lower than the OS of the
DC(s). Functional level should be upgraded to the highest possible level
whenever possible. Higher domain/forest functional level provides better
security.
Review AD availability
(existence of secondary /
backup domain
controller) for each site.
T22 Availability of AD
Each site in AD should have at least two DCs for availability reasons. In
case one DC fails, secondary DC can take over the role of the fail DC
and provide authentication service to users.
Determine if there are
backup procedures for
AD.
T23
Improper implementation of
AD backup
There should be a backup procedure describing backup of AD. AD
should be backed up and the backup should be tested for restoration
process. Retention period and backup period depend on each
organization's policy.
Check whether there are
periodic restore testing
procedures for AD
backup.
T24
Improper implementation of
AD backup
There should be a backup procedure describing backup of AD. AD
should be backed up and the backup should be tested for restoration
process. Retention period and backup period depend on each
organization's policy.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 110 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description
Personnel security T25
Insert subverted individuals
into organizations.
Adversary places individuals within organizations who are willing and
able to carry out actions to cause harm to organizational
missions/business functions.

T26
Insert subverted individuals
into privileged positions in
organizations.
Adversary places individuals in privileged positions within organizations
who are willing and able to carry out actions to cause harm to
organizational missions/business functions. Adversary may target
privileged functions to gain access to sensitive information (e.g., user
accounts, system files, etc.) and may leverage access to one privileged
capability to get to another capability.
Policy implementation
Identify whether existing
OU deployment is
suitable for GPO
implementation.
T27
Alignment between
business and AD structure
Structure of AD should be aligned with business to ease deployment of
policies, software, or other related AD management issues. For example
usually users and computers are separated due to the nature of GPO
that can be deployed for either users or computers or both. OUs are
usually represent the name of departments in the organization to ease
deployment of specific software to specific departments.
Review of security
settings policy
implementation: Account
policies (password
policies, account lockout
policy, Kerberos policy).
T28
Inadequate password
policy implementation
Password policies must be implemented properly to ensure security of
users account in the domain. Example of good password policies are:
password history must be enforced to at least 10 times, maximum and
minimum password age are set to at least 30 days and 1 day
respectively, minimum password length are set to at least 8 character
(preferable 9 if NTLM is still enabled in computers member in AD),
password complexity must be set, and store password using reversible
encryption must be disabled.

T29
Inadequate account
lockout policy
implementation
Account lockout policy must be set in way that it will minimize risk of
account brute force attack and minimize mass account lockout attack.
For example account lockout threshold should be set to a minimum
number such as 3 times, do not set it to 0 time as it may trigger massive
account lockout if a brute force attack is underway. Account lockout
duration and account reset counter should be set to a agreeable amount
of times defined by organization, for example 30 minutes.
Review of security
settings policy
implementation: audit
policy.
T30 Audit policy implementation
Correct audit policy implementation help in investigating a security
incidents case. Which part of audit policy that should be enabled usually
depends on the organization's policy. At least audit of success and failure
of authentication of account logon events must be enabled.
Review of security
settings policy
implementation: user
rights assignments.
T31 Symbolic links threat
This privilege determines if the user can create a symbolic link from the
computer he is logged on to. This privilege should only be given to
trusted users. Symbolic links can expose security vulnerabilities in
applications that arent designed to handle them.

T32 Modification of object label
This privilege determines which user accounts can modify the integrity
label of objects, such as files, registry keys, or processes owned by other
users. Processes running under a user account can modify the label of
an object owned by that user to a lower level without this privilege.

T33 Creation of global objects
This user right is required for a user account to create global objects
during Terminal Services sessions. Users can still create session-specific
objects without being assigned this user right. Assigning this user right
can be a security risk. Assign this user right only to trusted users.

T34
Impersonation a client after
authentication
Assigning this privilege to a user allows programs running on behalf of
that user to impersonate a client. Requiring this user right for this kind of
impersonation prevents an unauthorized user from convincing a client to
connect (for example, by remote procedure call (RPC) or named pipes) to
a service that they have created and then impersonating that client,
which can elevate the unauthorized user's permissions to administrative
or system levels.

T35
Lack of control on who can
log on through terminal
services
This security setting determines which users or groups have permission
to log on as a Terminal Services client. Default settings were: On
workstation and servers: Administrators, Remote Desktop Users. On
domain controllers: Administrators.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 111 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T36
Perform volume
maintenance tasks
This security setting determines which users and groups can run
maintenance tasks on a volume, such as remote defragmentation.
Use caution when assigning this user right. Users with this user right can
explore disks and extend files in to memory that contains other data.
When the extended files are opened, the user might be able to read and
modify the acquired data.

T37
Enable computer and user
accounts to be trusted for
delegation
This security setting determines which users can set the Trusted for
Delegation setting on a user or computer object. Misuse of this user right,
or of the Trusted for Delegation setting, could make the network
vulnerable to sophisticated attacks using Trojan horse programs that
impersonate incoming clients and use their credentials to gain access to
network resources.

T38
Synchronize directory
service data
This security setting determines which users and groups have the
authority to synchronize all directory service data. This is also known as
Active Directory synchronization.
Defaults: None.

T39 Deny logon locally
This security setting determines which users are prevented from logging
on at the computer. This policy setting supersedes the Allow log on
locally policy setting if an account is subject to both policies.

T40 Deny log on as a service
This security setting determines which service accounts are prevented
from registering a process as a service. This policy setting supersedes
the Log on as a service policy setting if an account is subject to both
policies.
Note: This security setting does not apply to the System, Local Service,
or Network Service accounts.
Default: None.

T41 Deny log on as a batch job
This security setting determines which accounts are prevented from
being able to log on as a batch job. This policy setting supersedes the
Log on as a batch job policy setting if a user account is subject to both
policies.
Default: None.

T42
Deny access to this
computer from the network
This security setting determines which users are prevented from
accessing a computer over the network. This policy setting supersedes
the Access this computer from the network policy setting if a user
account is subject to both policies.
Default: None.

T43
Take ownership of files or
other objects
This security setting determines which users can take ownership of any
securable object in the system, including Active Directory objects, files
and folders, printers, registry keys, processes, and threads.
Assigning this user right can be a security risk. Since owners of objects
have full control of them, only assign this user right to trusted users.
Default: Administrators.

T44 Shut down the system
This security setting determines which users who are logged on locally to
the computer can shut down the operating system using the Shut Down
command. Misuse of this user right can result in a denial of service.
Default on Workstations: Administrators, Backup Operators, Users.
Default on Servers: Administrators, Backup Operators.
Default on Domain controllers: Administrators, Backup Operators, Server
Operators, Print Operators

T45
Restore files and
directories
This security setting determines which users can bypass file, directory,
registry, and other persistent objects permissions when restoring backed
up files and directories, and determines which users can set any valid
security principal as the owner of an object.
Specifically, this user right is similar to granting the following permissions
to the user or group in question on all files and folders on the system:
Traverse Folder/Execute File and Write.
Assigning this user right can be a security risk. Since users with this user
right can overwrite registry settings, hide data, and gain ownership of
system objects, only assign this user right to trusted users.
Default:
Workstations and servers: Administrators, Backup Operators.
Domain controllers: Administrators, Backup Operators, Server Operators.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 112 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T46
Replace a process level
token
This security setting determines which user accounts can call the
CreateProcessAsUser() application programming interface (API) so that
one service can start another. An example of a process that uses this
user right is Task Scheduler. For information about Task Scheduler, see
Task Scheduler overview.
Default: Network Service, Local Service.

T47
Modify firmware
environment values
This security setting determines who can modify firmware environment
values. Firmware environment variables are settings stored in the
nonvolatile RAM of non-x86-based computers. The effect of the setting
depends on the processor.
On x86-based computers, the only firmware environment value that can
be modified by assigning this user right is the Last Known Good
Configuration setting, which should only be modified by the system.
On all computers, this user right is required to install or upgrade
Windows.
Default: Administrators.

T48
Manage auditing and
security log
This security setting determines which users can specify object access
auditing options for individual resources, such as files, Active Directory
objects, and registry keys.
This security setting does not allow a user to enable file and object
access auditing in general. For such auditing to be enabled, the Audit
object access setting in Computer Configuration\Windows
Settings\Security Settings\Local Policies\Audit Policies must be
configured.
You can view audited events in the security log of the Event Viewer. A
user with this privilege can also view and clear the security log.
Default: Administrators.

T49 Allow log on locally
This logon right determines which users can interactively log on to this
computer. Logons initiated by pressing CTRL+ALT+DEL sequence on
the attached keyboard requires the user to have this logon right.
Additionally this logon right may be required by some service or
administrative applications that can log on users. If you define this policy
for a user or group, you must also give the Administrators group this
right.
Default on workstations and servers: Administrators
Backup Operators
Users.
Default on domain controllers: Account Operators
Administrators
Backup Operators
Print Operators
Server Operators.

T50 Lock pages in memory
This security setting determines which accounts can use a process to
keep data in physical memory, which prevents the system from paging
the data to virtual memory on disk. Exercising this privilege could
significantly affect system performance by decreasing the amount of
available random access memory (RAM).
Default: None.

T51
Load and unload device
drivers
This user right determines which users can dynamically load and unload
device drivers or other code in to kernel mode. This user right does not
apply to Plug and Play device drivers. It is recommended that you do not
assign this privilege to other users.
Assigning this user right can be a security risk. Do not assign this user
right to any user, group, or process that you do not want to take over the
system.
Default on workstations and servers: Administrators.
Default on domain controllers:
Administrators
Print Operators
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 113 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T52
Adjust memory quotas for
a process
This privilege determines who can change the maximum memory that
can be consumed by a process.
This user right is defined in the Default Domain Controller Group Policy
object (GPO) and in the local security policy of workstations and servers.
Note: This privilege is useful for system tuning, but it can be misused, for
example, in a denial-of-service attack.
Default: Administrators
Local Service
Network Service.

T53 Generate security audits
This security setting determines which accounts can be used by a
process to add entries to the security log. The security log is used to
trace unauthorized system access. Misuse of this user right can result in
the generation of many auditing events, potentially hiding evidence of an
attack or causing a denial of service if the Audit: Shut down system
immediately if unable to log security audits security policy setting is
enabled. For more information see Audit: Shut down system immediately
if unable to log security audits
Default: Local Service
Network Service.

T54
Force shutdown from a
remote system
This security setting determines which users are allowed to shut down a
computer from a remote location on the network. Misuse of this user right
can result in a denial of service.
This user right is defined in the Default Domain Controller Group Policy
object (GPO) and in the local security policy of workstations and servers.
Default:
On workstations and servers: Administrators.
On domain controllers: Administrators, Server Operators.

T55 Debug programs
This user right determines which users can attach a debugger to any
process or to the kernel. Developers who are debugging their own
applications to not need to be assigned this user right. Developers who
are debugging new system components will need this user right to be
able to do so. This user right provides complete access to sensitive and
critical operating system components.
Assigning this user right can be a security risk. Only assign this user right
to trusted users.
Default: Administrators

T56 Create a token object
This security setting determines which accounts can be used by
processes to create a token that can then be used to get access to any
local resources when the process uses an internal application
programming interface (API) to create an access token.
This user right is used internally by the operating system. Unless it is
necessary, do not assign this user right to a user, group, or process other
than Local System.
Assigning this user right can be a security risk. Do not assign this user
right to any user, group, or process that you do not want to take over the
system.
Default: None

T57 Change the system time
This user right determines which users and groups can change the time
and date on the internal clock of the computer. Users that are assigned
this user right can affect the appearance of event logs. If the system time
is changed, events that are logged will reflect this new time, not the
actual time that the events occurred.
This user right is defined in the Default Domain Controller Group Policy
object (GPO) and in the local security policy of workstations and servers.
Default on workstations and servers:
Administrators
Local Service
Default on domain controllers:
Administrators
Server Operators
Local Service
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 114 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T58
Back up files and
directories
This user right determines which users can bypass file and directory,
registry, and other persistent object permissions for the purposes of
backing up the system.
Specifically, this user right is similar to granting the following permissions
to the user or group in question on all files and folders on the system:
Traverse Folder/Execute File
List Folder/Read Data
Read Attributes
Read Extended Attributes
Read Permissions
Assigning this user right can be a security risk. Since there is no way to
be sure that a user is backing up data, stealing data, or copying data to
be distributed, only assign this user right to trusted users.
Default on workstations and servers: Administrators
Backup Operators.
Default on domain controllers: Administrators
Backup Operators
Server Operators

T59
Add workstations to
domain
This security setting determines which groups or users can add
workstations to a domain.
This security setting is valid only on domain controllers. By default, any
authenticated user has this right and can create up to 10 computer
accounts in the domain.
Adding a computer account to the domain allows the computer to
participate in Active Directorybased networking. For example, adding a
workstation to a domain enables that workstation to recognize accounts
and groups that exist in Active Directory.
Default: Authenticated Users on domain controllers.
Note: Users who have the Create Computer Objects permission on the
Active Directory computers container can also create computer accounts
in the domain. The distinction is that users with permissions on the
container are not restricted to the creation of only 10 computer accounts.
In addition, computer accounts that are created by means of Add
workstations to domain have Domain Administrators as the owner of the
computer account, while computer accounts that are created by means of
permissions on the computers container have the creator as the owner of
the computer account. If a user has permissions on the container and
also has the Add workstations to domain user right, the computer is
added, based on the computer container permissions rather than on the
user right.

T60
Act as part of the operating
system
This user right allows a process to impersonate any user without
authentication. The process can therefore gain access to the same local
resources as that user.
Processes that require this privilege should use the Local System
account, which already includes this privilege, rather than using a
separate user account with this privilege specially assigned. If your
organization only uses servers that are members of the Windows Server
2003 family, you do not need to assign this privilege to your users.
However, if your organization uses servers running Windows 2000 or
Windows NT 4.0, you might need to assign this privilege to use
applications that exchange passwords in plaintext.
Assigning this user right can be a security risk. Only assign this user right
to trusted users.
Default: None.

T61
Access this computer from
the network
This user right determines which users and groups are allowed to
connect to the computer over the network. Terminal Services are not
affected by this user right.
Default on workstations and servers:
Administrators
Backup Operators
Users
Everyone
Default on domain controllers:
Administrators
Authenticated Users
Enterprise Domain Controllers
Everyone
Pre-Windows 2000 Compatible Access
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 115 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description
Review of security
settings policy
implementation: security
options.
T62
LM (LAN Manager)
password hash threat
OS passwords are easier to crack if they are saved in old LM format.
Password cracker could easily divide the hash and crack it separately,
lead to faster password cracking execution. The use of LM password
hash must be disabled throughout AD environment through the use of
security options policy: "Network security: Do not store LAN Manager
hash value on next password change"

T63
Recovery console: Allow
automatic administrative
logon
This security setting determines if the password for the Administrator
account must be given before access to the system is granted. If this
option is enabled, the Recovery Console does not require you to provide
a password, and it automatically logs on to the system.
Default: This policy is not defined and automatic administrative logon is
not allowed.

T64
Devices: Restrict CD-ROM
access to locally logged-on
user only
This security setting determines whether a CD-ROM is accessible to both
local and remote users simultaneously.
If this policy is enabled, it allows only the interactively logged-on user to
access removable CD-ROM media. If this policy is enabled and no one is
logged on interactively, the CD-ROM can be accessed over the network.
Default: This policy is not defined and CD-ROM access is not restricted to
the locally logged-on user.

T65
Interactive logon: Number
of previous logons to cache
(in case domain controller
is not available)
All previous users' logon information is cached locally so that, in the
event that a domain controller is unavailable during subsequent logon
attempts, they are able to log on . If a domain controller is unavailable
and a user's logon information is cached, the user is prompted with a
message that reads as follows:
Windows cannot connect to a server to confirm your logon settings. You
have been logged on using previously stored account information. If you
changed your account information since you last logged on to this
computer, those changes will not be reflected in this session.
If a domain controller is unavailable and a user's logon information is not
cached, the user is prompted with this message:
The system cannot log you on now because the domain
<DOMAIN_NAME> is not available.
In this policy setting, a value of 0 disables logon caching. Any value
above 50 only caches 50 logon attempts.
Default: 10

T66
Interactive logon: Require
Domain Controller
authentication to unlock
Logon information must be provided to unlock a locked computer. For
domain accounts, this security setting determines whether a domain
controller must be contacted to unlock a computer. If this setting is
disabled, a user can unlock the computer using cached credentials. If this
setting is enabled, a domain controller must authenticate the domain
account that is being used to unlock the computer.
Default: Disabled.

T67
User Account Control:
Behavior of the elevation
prompt for administrators in
Admin Approval Mode
This security setting determines the behavior of the elevation prompt for
administrators
The options are:
Prompt for consent: An operation that requires elevation of privilege will
prompt the Consent Admin to select either Permit or Deny. If the
Consent Admin selects Permit the operation will continue with their
highest available privilege. This option allows users to enter their name
and password to perform a privileged task.
Prompt for credentials: An operation that requires elevation of privilege
will prompt the Consent Admin to enter their user name and password. If
the user enters valid credentials the operation will continue with the
applicable privilege.
Elevate without prompting: This option allows the Consent Admin to
perform an operation that requires elevation without consent or
credentials. Note: this scenario should only be used in the most
constrained environments.
Default: Prompt for consent
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 116 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T68
User Account Control:
Behavior of the elevation
prompt for standard users
This security setting determines the behavior of the elevation prompt for
standard users
The options are:
Prompt for credentials: An operation that requires elevation of privilege
will prompt the user to enter an administrative user name and password.
If the user enters valid credentials the operation will continue with the
applicable privilege.
Automatically deny elevation requests: This option results in an access
denied error message being returned to the standard user when they try
to perform an operation that requires elevation of privilege. Most
enterprises running desktops as standard user will configure this policy to
reduce help desk calls.
Default: Prompt for credentials (home) / Automatically deny elevation
requests (enterprise)

T69
Interactive logon: Do not
require CTRL+ALT+DEL
This security setting determines whether pressing CTRL+ALT+DEL is
required before a user can log on.
If this policy is enabled on a computer, a user is not required to press
CTRL+ALT+DEL to log on. Not having to press CTRL+ALT+DEL leaves
users susceptible to attacks that attempt to intercept the users'
passwords. Requiring CTRL+ALT+DEL before users log on ensures that
users are communicating by means of a trusted path when entering their
passwords.
If this policy is disabled, any user is required to press CTRL+ALT+DEL
before logging on to Windows (unless they are using a smart card for
Windows logon).
Default on domain-computers: Disabled.
Default on stand-alone computers: Enabled.

T70
Interactive logon: Do not
display last user name
This security setting determines whether the name of the last user to log
on to the computer is displayed in the Windows logon screen.
If this policy is enabled, the name of the last user to successfully log on is
not displayed in the Log On to Windows dialog box.
If this policy is disabled, the name of the last user to log on is displayed.
Default: Disabled.

T71
Interactive logon: Message
text for users attempting to
log on
This security setting specifies a text message that is displayed to users
when they log on.
This text is often used for legal reasons, for example, to warn users about
the ramifications of misusing company information or to warn them that
their actions may be audited.
Default: No message.

T72
Shutdown: Allow system to
be shut down without
having to log on
This security setting determines whether a computer can be shut down
without having to log on to Windows.
When this policy is enabled, the Shut Down command is available on the
Windows logon screen.
When this policy is disabled, the option to shut down the computer does
not appear on the Windows logon screen. In this case, users must be
able to log on to the computer successfully and have the Shut down the
system user right before they can perform a system shutdown.
Default on workstations: Enabled.
Default on servers: Disabled.

T73
User Account Control: Only
elevate executables that
are signed and validated
This security setting will enforce PKI signature checks on any interactive
application that requests elevation of privilege. Enterprise administrators
can control the admin application allowed list thru the population of
certificates in the local computers Trusted Publisher Store.
The options are:
Enabled: Enforces the PKI certificate chain validation of a given
executable before it is permitted to run.
Disabled: Does not enforce PKI certificate chain validation before a
given executable is permitted to run.
Default: Disabled

T74
System Cryptography:
Force strong key protection
for user keys stored on the
computer
This security setting determines if users' private keys require a password
to be used.
The options are:
User input is not required when new keys are stored and used
User is prompted when the key is first used
User must enter a password each time they use a key
For more information, see Public key infrastructure.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 117 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description
Default: This policy is not defined.

T75
Audit: Shut down system
immediately if unable to log
security audits
This security setting determines whether the system shuts down if it is
unable to log security events.
If this security setting is enabled, it causes the system to stop if a security
audit cannot be logged for any reason. Typically, an event fails to be
logged when the security audit log is full and the retention method that is
specified for the security log is either Do Not Overwrite Events or
Overwrite Events by Days.
If the security log is full and an existing entry cannot be overwritten, and
this security option is enabled, the following Stop error appears:
STOP: C0000244 {Audit Failed}
An attempt to generate a security audit failed.
To recover, an administrator must log on, archive the log (optional), clear
the log, and reset this option as desired. Until this security setting is
reset, no users, other than a member of the Administrators group will be
able to log on to the system, even if the security log is not full.
Note: When configuring this security setting, changes will not take effect
until you restart Windows.
Default: Disabled.

T76
Network access: Do not
allow storage of credentials
or .NET Passports for
network authentication
This security setting determines whether Stored User Names and
Passwords saves passwords, credentials, or .NET Passports for later use
when it gains domain authentication.
If it is enabled, this setting prevents the Stored User Names and
Passwords from storing passwords and credentials.
Note: When configuring this security setting, changes will not take effect
until you restart Windows.
For more information about Stored User Names and Passwords, see
Stored User Names and Passwords.
Default: Disabled.

T77
Network access: Let
Everyone permissions
apply to anonymous users
This security setting determines what additional permissions are granted
for anonymous connections to the computer.
Windows allows anonymous users to perform certain activities, such as
enumerating the names of domain accounts and network shares. This is
convenient, for example, when an administrator wants to grant access to
users in a trusted domain that does not maintain a reciprocal trust. By
Default, the Everyone security identifier (SID) is removed from the token
created for anonymous connections. Therefore, permissions granted to
the Everyone group do not apply to anonymous users. If this option is
set, anonymous users can only access those resources for which the
anonymous user has been explicitly given permission.
If this policy is enabled, the Everyone SID is added to the token that is
created for anonymous connections. In this case, anonymous users are
able to access any resource for which the Everyone group has been
given permissions.
Default: Disabled.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 118 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T78
System cryptography: Use
FIPS compliant algorithms
for encryption, hashing and
signing
This security setting determines if the Transport Layer Security/Secure
Sockets Layer (TL/SS) Security Provider supports only the Transport
Layer Security (TLS) protocol as a client and as a server (if applicable). If
this setting is enabled, it uses only the Triple DES encryption algorithm
for the TLS traffic encryption, only the Rivest, Shamir, and Adleman
(RSA) public key algorithm for the TLS key exchange and authentication,
and only the Secure Hashing Algorithm 1 (SHA-1) for the TLS hashing
requirements.
For Encrypting File System Service (EFS), it supports only the Triple
Data Encryption Standard (DES) encryption algorithm for encrypting file
data supported by the NTFS file system. By default, EFS uses the
Advanced Encryption Standard (AES) algorithm with a 256-bit key in the
Windows Server 2003 family and DESX algorithm in Windows XP for
encrypting file data. For information about EFS, see Encrypting File
System.
For Terminal Services, it supports only the Triple DES encryption
algorithm for encrypting terminal services network communication. For
information about Terminal Services, see Terminal Services.
Default: Disabled.
Note: The Federal Information Processing Standard (FIPS) 140-1 is a
security implementation designed for certifying cryptographic software.
FIPS 140-1 validated software is required by the U.S. Government and
requested by other prominent institutions.

T79
Network access: Sharing
and security model for local
accounts
This security setting determines how network logons using local accounts
are authenticated. If this setting is set to Classic, network logons that use
local account credentials authenticate by using those credentials. The
Classic model allows fine control over access to resources. By using the
Classic model, you can grant different types of access to different users
for the same resource.
If this setting is set to Guest only, network logons that use local accounts
are automatically mapped to the Guest account. By using the Guest
model, you can have all users treated equally. All users authenticate as
Guest, and they all receive the same level of access to a given resource,
which can be either Read-only or Modify.
Default on domain computers: Classic.
Default on stand-alone computers: Guest only

T80
Audit: Audit the use of
Backup and Restore
privilege
This security setting determines whether to audit the use of all user
privileges, including Backup and Restore, when the Audit privilege use
policy is in effect. Enabling this option when the Audit privilege use policy
is also enabled generates an audit event for every file that is backed up
or restored.
If you disable this policy, then use of the Backup or Restore privilege is
not audited even when Audit privilege use is enabled.
Note: When configuring this security setting, changes will not take effect
until you restart Windows.
Default: Disabled.

T81
Accounts: Limit local
account use of blank
passwords to console
logon only
This security setting determines whether local accounts that are not
password protected can be used to logon from locations other than the
physical computer console. If enabled, then local accounts that are not
password protected will only be able to log on at the computer's
keyboard.
Default: Enabled.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 119 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T82
Network security: LAN
Manager authentication
level
This security setting determines which challenge/response authentication
protocol is used for network logons. This choice affects the level of
authentication protocol used by clients, the level of session security
negotiated, and the level of authentication accepted by servers as
follows:
Send LM & NTLM responses: Clients use LM and NTLM authentication
and never use NTLMv2 session security; domain controllers accept LM,
NTLM, and NTLMv2 authentication.
Send LM & NTLM - use NTLMv2 session security if negotiated: Clients
use LM and NTLM authentication and use NTLMv2 session security if the
server supports it; domain controllers accept LM, NTLM, and NTLMv2
authentication.
Send NTLM response only: Clients use NTLM authentication only and
use NTLMv2 session security if the server supports it; domain controllers
accept LM, NTLM, and NTLMv2 authentication.
Send NTLMv2 response only: Clients use NTLMv2 authentication only
and use NTLMv2 session security if the server supports it; domain
controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLMv2 response only\refuse LM: Clients use NTLMv2
authentication only and use NTLMv2 session security if the server
supports it; domain controllers refuse LM (accept only NTLM and
NTLMv2 authentication).
Send NTLMv2 response only\refuse LM & NTLM: Clients use NTLMv2
authentication only and use NTLMv2 session security if the server
supports it; domain controllers refuse LM and NTLM (accept only
NTLMv2 authentication).Default:
Send LM & NTLM responses on server.
Undefined on workstations.

T83
Network security: Minimum
session security for NTLM
SSP based (including
secure RPC) clients and
servers
This security setting allows a client to require the negotiation of 128-bit
encryption and/or NTLMv2 session security. These values are dependent
on the LAN Manager Authentication Level security setting value. The
options are:
Require NTLMv2 session security: The connection will fail if NTLMv2
protocol is not negotiated.
Require 128-bit encryption: The connection will fail if strong encryption
(128-bit) is not negotiated.
Default: No requirements.

T84
Network security: Do not
store LAN Manager hash
value on next password
change
This security setting determines if, at the next password change, the LAN
Manager (LM) hash value for the new password is stored. The LM hash
is relatively weak and prone to attack, as compared with the
cryptographically stronger Windows NT hash. Since the LM hash is
stored on the local computer in the security database the passwords can
be compromised if the security database is attacked.
Default on Windows Vista: Enabled
Default on Windows XP: Disabled.

T85
Network access: Do not
allow anonymous
enumeration of SAM
accounts and shares
This security setting determines whether anonymous enumeration of
SAM accounts and shares is allowed.
Windows allows anonymous users to perform certain activities, such as
enumerating the names of domain accounts and network shares. This is
convenient, for example, when an administrator wants to grant access to
users in a trusted domain that does not maintain a reciprocal trust. If you
do not want to allow anonymous enumeration of SAM accounts and
shares, then enable this policy.
Default: Disabled.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 120 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T86
Network access: Do not
allow anonymous
enumeration of SAM
accounts
This security setting determines what additional permissions will be
granted for anonymous connections to the computer.
Windows allows anonymous users to perform certain activities, such as
enumerating the names of domain accounts and network shares. This is
convenient, for example, when an administrator wants to grant access to
users in a trusted domain that does not maintain a reciprocal trust.
This security option allows additional restrictions to be placed on
anonymous connections as follows:
Enabled: Do not allow enumeration of SAM accounts. This option
replaces Everyone with Authenticated Users in the security permissions
for resources.
Disabled: No additional restrictions. Rely on default permissions.
Default on workstations: Enabled.
Default on server: Disabled.
Important
This policy has no impact on domain controllers.

T87
Network access: Remotely
accessible registry paths
This security setting determines which registry paths can be accessed
over the network, regardless of the users or groups listed in the access
control list (ACL) of the winreg registry key.
Default:
System\CurrentControlSet\Control\ProductOptions
System\CurrentControlSet\Control\Server Applications
Software\Microsoft\Windows NT\CurrentVersion
Incorrectly editing the registry may severely damage your system. Before
making changes to the registry, you should back up any valued data on
the computer.

T88
Shutdown: Clear virtual
memory pagefile
This security setting determines whether the virtual memory pagefile is
cleared when the system is shut down.
Virtual memory support uses a system pagefile to swap pages of memory
to disk when they are not used. On a running system, this pagefile is
opened exclusively by the operating system, and it is well protected.
However, systems that are configured to allow booting to other operating
systems might have to make sure that the system pagefile is wiped clean
when this system shuts down. This ensures that sensitive information
from process memory that might go into the pagefile is not available to an
unauthorized user who manages to directly access the pagefile.
When this policy is enabled, it causes the system pagefile to be cleared
upon clean shutdown. If you enable this security option, the hibernation
file (hiberfil.sys) is also zeroed out when hibernation is disabled on a
portable computer system.
Default: Disabled.

T89
System objects:
Strengthen default
permissions of internal
system objects (e.g.,
Symbolic Links)
This security setting determines the strength of the default discretionary
access control list (DACL) for objects.
Active Directory maintains a global list of shared system resources, such
as DOS device names, mutexes, and semaphores. In this way, objects
can be located and shared among processes. Each type of object is
created with a default DACL that specifies who can access the objects
and what permissions are granted.
If this policy is enabled, the default DACL is stronger, allowing users who
are not administrators to read shared objects but not allowing these users
to modify shared objects that they did not create.
Default: Enabled.

T90
Microsoft network server:
Digitally sign
communications (if client
agrees)
This security setting determines whether the SMB server will negotiate
SMB packet signing with clients that request it.
The server message block (SMB) protocol provides the basis for
Microsoft file and print sharing and many other networking operations,
such as remote Windows administration. To prevent man-in-the-middle
attacks that modify SMB packets in transit, the SMB protocol supports
the digital signing of SMB packets. This policy setting determines
whether the SMB server will negotiate SMB packet signing when an SMB
client requests it.
If this setting is enabled, the Microsoft network server will negotiate SMB
packet signing as requested by the client. That is, if packet signing has
been enabled on the client, packet signing will be negotiated. If this policy
is disabled, the SMB client will never negotiate SMB packet signing.
Default: Enabled on domain controllers only.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 121 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T91
Microsoft network server:
Digitally sign
communications (always)
This security setting determines whether packet signing is required by the
SMB server component.
The server message block (SMB) protocol provides the basis for
Microsoft file and print sharing and many other networking operations,
such as remote Windows administration. To prevent "man-in-the-middle"
attacks that modify SMB packets in transit, the SMB protocol supports
the digital signing of SMB packets. This policy setting determines
whether SMB packet signing must be negotiated before further
communication with an SMB client is permitted.
If this setting is enabled, the Microsoft network server will not
communicate with a Microsoft network client unless that client agrees to
perform SMB packet signing. If this setting is disabled, SMB packet
signing is negotiated between the client and server.
Default:
Disabled for member servers.
Enabled for domain controllers.

T92
Microsoft network client:
Send unencrypted
password to connect to
third-party SMB servers
If this security setting is enabled, the Server Message Block (SMB)
redirector is allowed to send plaintext passwords to non-Microsoft SMB
servers that do not support password encryption during authentication.
Sending unencrypted passwords is a security risk.
Default: Disabled.

T93
Microsoft network client:
Digitally sign
communications (if server
agrees)
This security setting determines whether the SMB client attempts to
negotiate SMB packet signing.
The server message block (SMB) protocol provides the basis for
Microsoft file and print sharing and many other networking operations,
such as remote Windows administration. To prevent man-in-the-middle
attacks that modify SMB packets in transit, the SMB protocol supports
the digital signing of SMB packets. This policy setting determines
whether the SMB client component attempts to negotiate SMB packet
signing when it connects to an SMB server.
If this setting is enabled, the Microsoft network client will ask the server to
perform SMB packet signing upon session setup. If packet signing has
been enabled on the server, packet signing will be negotiated. If this
policy is disabled, the SMB client will never negotiate SMB packet
signing.
Default: Enabled.

T94
Microsoft network client:
Digitally sign
communications (always)
This security setting determines whether packet signing is required by the
SMB client component.
The server message block (SMB) protocol provides the basis for
Microsoft file and print sharing and many other networking operations,
such as remote Windows administration. To prevent man-in-the-middle
attacks that modify SMB packets in transit, the SMB protocol supports
the digital signing of SMB packets. This policy setting determines
whether SMB packet signing must be negotiated before further
communication with an SMB server is permitted.
If this setting is enabled, the Microsoft network client will not
communicate with a Microsoft network server unless that server agrees
to perform SMB packet signing. If this policy is disabled, SMB packet
signing is negotiated between the client and server.
Default: Disabled.

T95
Network security: LDAP
client signing requirements
This security setting determines the level of data signing that is requested
on behalf of clients issuing LDAP BIND requests, as follows:
None: The LDAP BIND request is issued with the options that are
specified by the caller.
Negotiate signing: If Transport Layer Security/Secure Sockets Layer
(TLS\SSL) has not been started, the LDAP BIND request is initiated with
the LDAP data signing option set in addition to the options specified by
the caller. If TLS\SSL has been started, the LDAP BIND request is
initiated with the options that are specified by the caller.
Require signature: This is the same as Negotiate signing. However, if the
LDAP server's intermediate saslBindInProgress response does not
indicate that LDAP traffic signing is required, the caller is told that the
LDAP BIND command request failed.
If you set the server to Require signature, you must also set the client.
Not setting the client results in a loss of connection with the server.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 122 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T96
Domain member: Disable
machine account password
changes
Determines whether a domain member periodically changes its computer
account password. If this setting is enabled, the domain member does
not attempt to change its computer account password. If this setting is
disabled, the domain member attempts to change its computer account
password as specified by the setting for Domain Member: Maximum age
for machine account password, which by default is every 30 days.
Default: Disabled.

T97
Domain member: Digitally
encrypt or sign secure
channel data (always)
This security setting determines whether all secure channel traffic
initiated by the domain member must be signed or encrypted.
When a computer joins a domain, a computer account is created. After
that, when the system starts, it uses the computer account password to
create a secure channel with a domain controller for its domain. This
secure channel is used to perform operations such as NTLM pass
through authentication, LSA SID/name Lookup etc.
This setting determines whether or not all secure channel traffic initiated
by the domain member meets minimum security requirements.
Specifically it determines whether all secure channel traffic initiated by
the domain member must be signed or encrypted. If this policy is
enabled, then the secure channel will not be established unless either
signing or encryption of all secure channel traffic is negotiated. If this
policy is disabled, then encryption and signing of all secure channel traffic
is negotiated with the Domain Controller in which case the level of
signing and encryption depends on the version of the Domain Controller
and the settings of the following two policies:
Domain member: Digitally encrypt secure channel data (when possible)
Domain member: Digitally sign secure channel data (when possible)
Default: Enabled.

T98
Domain member: Require
strong (Windows 2000 or
later) session key
This security setting determines whether 128-bit key strength is required
for encrypted secure channel data.
When a computer joins a domain, a computer account is created. After
that, when the system starts, it uses the computer account password to
create a secure channel with a domain controller within the domain. This
secure channel is used to perform operations such as NTLM passthrough
authentication, LSA SID/name Lookup, and so on.
Depending on what version of Windows is running on the domain
controller that the domain member is communicating with and the
settings of the parameters:
Domain member: Digitally encrypt or sign secure channel data (always)
Domain member: Digitally encrypt secure channel data (when possible)
Some or all of the information that is transmitted over the secure channel
will be encrypted. This policy setting determines whether or not 128-bit
key strength is required for the secure channel information that is
encrypted.
If this setting is enabled, then the secure channel will not be established
unless 128-bit encryption can be performed. If this setting is disabled,
then the key strength is negotiated with the domain controller.
Default: Disabled.

T99
Domain member: Digitally
encrypt secure channel
data (when possible)
This security setting determines whether a domain member attempts to
negotiate encryption for all secure channel traffic that it initiates.
When a computer joins a domain, a computer account is created. After
that, when the system starts, it uses the computer account password to
create a secure channel with a domain controller for its domain. This
secure channel is used to perform operations such as NTLM passthrough
authentication, LSA SID/name Lookup etc.
This setting determines whether or not the domain member attempts to
negotiate encryption for all secure channel traffic that it initiates. If
enabled, the domain member will request encryption of all secure
channel traffic. If the domain controller supports encryption of all secure
channel traffic, then all secure channel traffic will be encrypted.
Otherwise only logon information transmitted over the secure channel will
be encrypted. If this setting is disabled, then the domain member will not
attempt to negotiate secure channel encryption.
Default: Enabled.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 123 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T100
Domain member: Digitally
sign secure channel data
(when possible)
This security setting determines whether a domain member attempts to
negotiate signing for all secure channel traffic that it initiates.
When a computer joins a domain, a computer account is created. After
that, when the system starts, it uses the computer account password to
create a secure channel with a domain controller for its domain. This
secure channel is used to perform operations such as NTLM pass
through authentication, LSA SID/name Lookup etc.
This setting determines whether or not the domain member attempts to
negotiate signing for all secure channel traffic that it initiates. If enabled,
the domain member will request signing of all secure channel traffic. If
the Domain Controller supports signing of all secure channel traffic, then
all secure channel traffic will be signed which ensures that it cannot be
tampered with in transit.
Default: Enabled.

T101
Domain controller: LDAP
server signing
requirements
This security setting determines whether the LDAP server requires
signing to be negotiated with LDAP clients, as follows:
None: Data signing is not required in order to bind with the server. If the
client requests data signing, the server supports it.
Require signature: Unless TLS\SSL is being used, the LDAP data signing
option must be negotiated.
Default: This policy is not defined, which has the same effect as None.
If you set the server to Require Signature, you must also set the client.
Not setting the client results in loss of connection with the server.

T102
Network access: Allow
anonymous SID/name
translation
This security setting determines if an anonymous user can request
security identifier (SID) attributes for another user.
If this policy is enabled, a user with knowledge of an administrator's SID
could contact a computer that has this policy enabled and use the SID to
get the administrator's name.
Default on workstations and member servers: Disabled.
Default on domain controllers: Enabled.

T103
Accounts: Rename guest
account
This security setting determines whether a different account name is
associated with the security identifier (SID) for the account "Guest."
Renaming the well-known Guest account makes it slightly more difficult
for unauthorized persons to guess this user name and password
combination.
Default: Guest.

T104
Accounts: Rename
administrator account
This security setting determines whether a different account name is
associated with the security identifier (SID) for the account Administrator.
Renaming the well-known Administrator account makes it slightly more
difficult for unauthorized persons to guess this privileged user name and
password combination.
Default: Administrator.

T105
Accounts: Guest account
status
This security setting determines if the Guest account is enabled or
disabled.
Default: Disabled.
Note: If the Guest account is disabled and the security option Network
Access: Sharing and Security Model for local accounts is set to Guest
Only, network logons, such as those performed by the Microsoft Network
Server (SMB Service), will fail.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 124 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T106
Accounts: Administrator
account status
This security setting determines whether the local Administrator account
is enabled or disabled.
Notes
If you try to re-enable the Administrator account after it has been
disabled, and if the current Administrator password does not meet the
password requirements, you cannot re-enable the account. In this case,
an alternative member of the Administrators group must reset the
password on the Administrator account. For information about how to
reset a password, see To reset a password.
Disabling the Administrator account can become a maintenance issue
under certain circumstances. For example, in a domain environment, if
the secure channel that constitutes your join fails for any reason, and
there is no other local Administrator account, you must restart in Safe
Mode to fix the problem that is causing your join status to be broken.
Under Safe Mode boot, the Administrator account is always enabled,
regardless of this setting.
Default: Enabled.
Review of security
settings policy
implementation: event
log.
T107
Insufficient log monitoring
capabilities
Log monitoring must be enabled throughout all AD environment. Log
must be configured to be able to collect at least data from the current
month to ease investigation should there be a security breach. Configure
system and application log size at least 5 times of its default value and
configure also security log size value to at least 10 times of its default
value. Configure also log to be overwritten as the size reached its
maximum size value.
Security of AD
computer members

Identify patch
management system
(patch for OS and
applications).
T108 Incomplete patch threat
Patches deployment should be complete and uniform throughtout AD
infrastructure. There should be patch management that control which
patch should be deployed and when. Administrators should also check
patch reporting console regularly and implement patches on computers
that lack of them.
Identify existence of
application whitelisting
(permitted applications) in
servers and workstations.
T109
Installation of unauthorized
applications
A whitelist of applications that can be installed should be identified,
documented and followed. This minimizes the risk of security breach
through unauthorized applications.

T110
Insert targeted malware
into organizational
information systems and
information system
components.
Adversary inserts malware into organizational information systems and
information system components (e.g., commercial or free information
technology products), specifically targeted to the hardware, software, and
firmware used by organizations (based on knowledge gained via
reconnaissance).
Identify controlled used of
administrative privilege.
T111
High privilege account
threat
High privilege accounts (domain admins, enterprise admins, schema
admins, restricted groups that has access to workstations, etc) must be
limited, controlled, and logged. If an attacker could gain access as a
domain admin, for example, he/she could control the entire computers
and data in the AD. Restricted groups/accounts should also be identify to
detect improper use of delegation task.
Identify if there is secure
configurations or
procedures for deploying
servers and workstations
(for example: disabling
unrequired applications
or services, patching
before deploying servers
or workstations).
T112
Lack of basic security
hardening
Servers and workstations, and all computers member of AD, should have
basic level of hardening. There should also hardening documentation that
describe the hardening process and what should be done to achieve a
good hardening standard as required by the organization. Hardening
usually includes disabling unrequired applications or services and
patching process before deploying servers or workstations.

T113
Incorrect configuration of
anti-virus
Anti-virus should be correctly configured. Correct configuration of anti-
virus includes uniformly deployed of anti-virus software throughout AD
environment (all AD computer members must have anti-virus deployed),
antivirus software could not be able to be disabled or removed even by
administrators, automatic update of signature files, and always up-to-date
antivirus database and application.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 125 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T114 Incomplete patch threat
Patches deployment should be complete and uniform throughout AD
infrastructure. There should be patch management that control which
patch should be deployed and when. Administrators should also check
patch reporting console regularly and implement patches on computers
that lack of them.

T115
Installation of unauthorized
applications
A whitelist of applications that can be installed should be identified,
documented and followed. This minimize the risk of security breach
through unauthorized applications.
Identify correct
deployment of anti-virus
and anti-malware
software (check if
antivirus software has
been installed, determine
if antivirus software can
be disabled or removed,
check if the signature
files are updated
regularly).
T116
Incorrect configuration of
anti-virus
Anti-virus should be correctly configured. Correct configuration of anti-
virus includes uniformly deployed of anti-virus software throughout AD
environment (all AD computer members must have anti-virus deployed),
antivirus software could not be able to be disabled or removed even by
administrators, automatic update of signature files, and always up-to-date
antivirus database and application.
Identify removable and
portable media control.
T117
Boot using alternative OS
threat
DC and computer member of AD should be protected from portable
bootable media via USB or CD/DVD player. If an attacker could boot a
computer member from bootable media, he/she could extract password
hashes from computer's SAM database and crack it using a password
cracker program. If this attack is performed on DC, the attacker could
gain access to all password hashes of all users in the domain.

T118 Data theft Data theft could also occur if portable media usage is not controlled.

T119
Perform malware-directed
internal reconnaissance.
Adversary uses malware installed inside the organizational perimeter to
identify targets of opportunity. Because the scanning, probing, or
observation does not cross the perimeter, it is not detected by externally
placed intrusion detection systems.

T120
Deliver malware by
providing removable
media.
Adversary places removable media (e.g., flash drives) containing
malware in locations external to organizational physical perimeters but
where employees are likely to find the media (e.g., facilities parking lots,
exhibits at conferences attended by employees) and use it on
organizational information systems.
Identify continues
vulnerability scanning
processes for AD
computer members.
T121 Lack of vulnerability
assessment
Regular vulnerability assessment is a in important process of securing
network and overall AD computer members. This assessment helps
identifies threat and vulnerability in every computers member of an AD,
including its DC. Vulnerability assessment must be conducted regularly,
once a year or every half a year, depend on the organization's policy.
Mitigation of identified vulnerabilities must be followed afterwards.
Identify data recovery
capability.
T122
Improper implementation of
AD backup
There should be a backup procedure describing backup of AD. AD
should be backed up and the backup should be tested for restoration
process. Retention period and backup period depend on each
organization's policy.
Identify whether host-
based firewall is
configured.
T123
Lack of host-based firewall
implementation
A well configured firewall can thwart many security incidents and
minimize the risk of successful exploit attacks. Firewall of all computers
throughout AD environment must be configured in accordance to
business needs and follow the concept of least privilege. This means only
needed services pr ports are allowed to pass through the firewall.
Identify whether there
users education and
awareness.
T124 Lack of users' education on
IT security
People are the weakest link in IT security. Good security awareness and
education to users are essentials to build secure AD environment. Lack
of security education and awareness on IT security could lead to security
breach due to either users' negligence or lack of knowledge on
implementing a secure daily computing activities.
Identify whether LanMan
is still used on servers/
workstations.
T125 LM (LAN Manager)
password hash threat
OS passwords are easier to crack if they are saved in old LM format.
Password cracker could easily divide the hash and crack it separately,
lead to faster password cracking execution. The use of LM password
hash must be disabled throughout AD environment through the use of
security options policy: "Network security: Do not store LAN Manager
hash value on next password change"
Identify whether there are
security-related incidents
T126 Recurring security
incidents
Helpdesk log should be investigated for recurring security incidents.
Security incidents must be closed and dealt properly to mitigate
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 126 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description
in helpdesk logs. recurrence.
Identify exploits and
attacks
T127
Exploit physical access of
authorized staff to gain
access to organizational
facilities.
Adversary follows (tailgates) authorized individuals into
secure/controlled locations with the goal of gaining access to facilities,
circumventing physical security checks.

T128
Exploit poorly configured or
unauthorized information
systems exposed to the
Internet.
Adversary gains access through the Internet to information systems that
are not authorized for Internet connectivity or that do not meet
organizational configuration requirements.

T129
Exploit split tunneling.
Adversary takes advantage of external organizational or personal
information systems (e.g., laptop computers at remote locations) that are
simultaneously connected securely to organizational information systems
or networks and to non-secure remote connections.

T130
Exploit known
vulnerabilities in mobile
systems (e.g., laptops,
PDAs, smart phones).
Adversary takes advantage of fact that transportable information systems
are outside physical protection of organizations and logical protection of
corporate firewalls, and compromises the systems based on known
vulnerabilities to gather information from those systems.

T131 Exploit recently discovered
vulnerabilities.
Adversary exploits recently discovered vulnerabilities in organizational
information systems in an attempt to compromise the systems before
mitigation measures are available or in place.

T132
Exploit vulnerabilities on
internal organizational
information systems.
Adversary searches for known vulnerabilities in organizational internal
information systems and exploits those vulnerabilities.

T133 Exploit vulnerabilities using
zero-day attacks.
Adversary employs attacks that exploit as yet unpublicized vulnerabilities.
Zero-day attacks are based on adversary insight into the information
systems and applications used by organizations as well as adversary
reconnaissance of organizations.

T134
Exploit vulnerabilities in
information systems timed
with organizational
mission/business
operations tempo.
Adversary launches attacks on organizations in a time and manner
consistent with organizational needs to conduct mission/business
operations.

T135
Compromise critical
information systems via
physical access.
Adversary obtains physical access to organizational information systems
and makes modifications.

T136
Compromise information
systems or devices used
externally and reintroduced
into the enterprise.
Adversary installs malware on information systems or devices while the
systems/devices are external to organizations for purposes of
subsequently infecting organizations when reconnected.

T137
Compromise software of
organizational critical
information systems.
Adversary inserts malware or otherwise corrupts critical internal
organizational information systems.

T138
Compromise organizational
information systems to
facilitate exfiltration of
data/information.
Adversary implants malware into internal organizational information
systems, where the malware over time can identify and then exfiltrate
valuable information.

T139 Compromise mission-
critical information.
Adversary compromises the integrity of mission-critical information, thus
preventing or impeding ability of organizations to which information is
supplied, from carrying out operations.

T140 Conduct communications
interception attacks.
Adversary takes advantage of communications that are either
unencrypted or use weak encryption (e.g., encryption containing
publically known flaws), targets those communications, and gains access
to transmitted information and channels.

T141 Conduct wireless jamming
attacks.
Adversary takes measures to interfere with wireless communications so
as to impede or prevent communications from reaching intended
recipients.

T142
Conduct attacks using
unauthorized ports,
protocols and services.
Adversary conducts attacks using ports, protocols, and services for
ingress and egress that are not authorized for use by organizations.

T143
Conduct attacks leveraging
traffic/data movement
allowed across perimeter.
Adversary makes use of permitted information flows (e.g., email
communication, removable storage) to compromise internal information
systems, which allows adversary to obtain and exfiltration of sensitive
information through perimeters.

T144
Conduct simple Denial of
Service (DoS) attack.
Adversary attempts to make an Internet-accessible resource unavailable
to intended users, or prevent the resource from functioning efficiently or
at all, temporarily or indefinitely.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 127 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T145 Conduct Distributed Denial
of Service (DDoS) attacks.
Adversary uses multiple compromised information systems to attack a
single target, thereby causing denial of service for users of the targeted
information systems.

T146 Conduct targeted Denial of
Service (DoS) attacks.
Adversary targets DoS attacks to critical information systems,
components, or supporting infrastructures, based on adversary
knowledge of dependencies.

T147 Conduct physical attacks
on organizational facilities.
Adversary conducts a physical attack on organizational facilities (e.g.,
sets a fire).

T148
Conduct physical attacks
on infrastructures
supporting organizational
facilities.
Adversary conducts a physical attack on one or more infrastructures
supporting organizational facilities (e.g., breaks a water main, cuts a
power line).

T149
Conduct brute force login
attempts/password
guessing attacks.
Adversary attempts to gain access to organizational information systems
by random or systematic guessing of passwords, possibly supported by
password cracking utilities.

T150 Conduct non-targeted
zero-day attacks.
Adversary employs attacks that exploit as yet unpublicized vulnerabilities.
Attacks are not based on any adversary insights into specific
vulnerabilities of organizations.

T151 Conduct internally-based
session hijacking.
Adversary places an entity within organizations in order to gain access to
organizational information systems or networks for the express purpose
of taking control (hijacking) an already established, legitimate session
either between organizations and external entities (e.g., users connecting
from remote locations) or between two locations within internal networks.

T152
Conduct internally-based
network traffic modification
(man in the middle)
attacks.
Adversary operating within the organizational infrastructure intercepts
and corrupts data sessions.

T153
Conduct outsider-based
social engineering to obtain
information.
Externally placed adversary takes actions (e.g., using email, phone) with
the intent of persuading or otherwise tricking individuals within
organizations into revealing critical/sensitive information (e.g., personally
identifiable information).

T154
Conduct insider-based
social engineering to obtain
information.
Internally placed adversary takes actions (e.g., using email, phone) so
that individuals within organizations reveal critical/sensitive information
(e.g., mission information).

T155
Conduct attacks targeting
and compromising
personal devices of critical
employees.
Adversary targets key organizational employees by placing malware on
their personally owned information systems and devices (e.g.,
laptop/notebook computers, personal digital assistants, smart phones).
The intent is to take advantage of any instances where employees use
personal information systems or devices to handle critical/sensitive
information.

T156 Obtain sensitive
information via exfiltration.
Adversary directs malware on organizational systems to locate and
surreptitiously transmit sensitive information.

T157
Cause degradation or
denial of attacker-selected
services or capabilities.
Adversary directs malware on organizational systems to impair the
correct and timely support of organizational mission/business functions.

T158
Cause
deterioration/destruction of
critical information system
components and functions.
Adversary destroys or causes deterioration of critical information system
components to impede or eliminate organizational ability to carry out
missions or business functions. Detection of this action is not a concern.

T159
Cause integrity loss by
creating, deleting, and/or
modifying data on publicly
accessible information
systems (e.g., web
defacement).
Adversary vandalizes, or otherwise makes unauthorized changes to,
organizational websites or data on websites.

T160
Cause integrity loss by
polluting or corrupting
critical data.
Adversary implants corrupted and incorrect data in critical data, resulting
in suboptimal actions or loss of confidence in organizational
data/services.

T161
Cause integrity loss by
injecting false but
believable data into
organizational information
systems.
Adversary injects false but believable data into organizational information
systems, resulting in suboptimal actions or loss of confidence in
organizational data/services.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 128 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T162
Cause disclosure of critical
and/or sensitive
information by authorized
users.
Adversary induces (e.g., via social engineering) authorized users to
inadvertently expose, disclose, or mishandle critical/sensitive information.

T163
Cause unauthorized
disclosure and/or
unavailability by spilling
sensitive information.
Adversary contaminates organizational information systems (including
devices and networks) by causing them to handle information of a
classification/sensitivity for which they have not been authorized. The
information is exposed to individuals who are not authorized access to
such information, and the information system, device, or network is
unavailable while the spill is investigated and mitigated.

T164
Obtain information by
externally located
interception of wireless
network traffic.
Adversary intercepts organizational communications over wireless
networks. Examples include targeting public wireless access or hotel
networking connections, and drive-by subversion of home or
organizational wireless routers.

T165 Obtain unauthorized
access.
Adversary with authorized access to organizational information systems,
gains access to resources that exceeds authorization.

T166
Obtain sensitive
data/information from
publicly accessible
information systems.
Adversary scans or mines information on publically accessible servers
and web pages of organizations with the intent of finding sensitive
information.

T167
Obtain information by
opportunistically stealing or
scavenging information
systems/components.
Adversary steals information systems or components (e. g., laptop
computers or data storage media) that are left unattended outside of

T168
Coordinate a campaign of
multi-staged attacks (e.g.,
hopping).
Adversary moves the source of malicious commands or actions from one
compromised information system to another, making analysis difficult.
Identify users related
threats
T169
Spill sensitive information
Authorized user erroneously contaminates a device, information system,
or network by placing on it or sending to it information of a
classification/sensitivity which it has not been authorized to handle. The
information is exposed to access by unauthorized individuals, and as a
result, the device, system, or network is unavailable while the spill is
investigated and mitigated.

T170
Mishandling of critical
and/or sensitive
information by authorized
users
Authorized privileged user inadvertently exposes critical/sensitive
information.

T171
Incorrect privilege settings
Authorized privileged user or administrator erroneously assigns a user
exceptional privileges or sets privilege requirements on a resource too
low.

T172 Communications
contention
Degraded communications performance due to contention.

T173
Unreadable display Display unreadable due to aging equipment.
Identify natural threats
T174
Earthquake at primary
facility
Earthquake of organization-defined magnitude at primary facility makes
facility inoperable.

T175
Fire at primary facility
Fire (not due to adversarial activity) at primary facility makes facility
inoperable.

T176
Fire at backup facility
Fire (not due to adversarial activity) at backup facility makes facility
inoperable or destroys backups of software, configurations, data, and/or
logs.

T177
Flood at primary facility
Flood (not due to adversarial activity) at primary facility makes facility
inoperable.

T178
Flood at backup facility
Flood (not due to adversarial activity) at backup facility makes facility
inoperable or destroys backups of software, configurations, data, and/or
logs.

T179
Hurricane at primary facility
Hurricane of organization-defined strength at primary facility makes
facility inoperable.

T180
Hurricane at backup facility
Hurricane of organization-defined strength at backup facility makes
facility inoperable or destroys backups of software, configurations, data,
and/or logs.
Identify hardware related
threats
T181
Resource depletion Degraded processing performance due to resource depletion.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 129 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T182
Introduction of
vulnerabilities into software
products
Due to inherent weaknesses in programming languages and software
development environments, errors and vulnerabilities are introduced into
commonly used software products.

T183
Disk error Corrupted storage due to a disk error.

T184
Pervasive disk error
Multiple disk errors due to aging of a set of devices all acquired at the
same time, from the same supplier.

T185 Windstorm/tornado at
primary facility
Windstorm/tornado of organization-defined strength at primary facility
makes facility inoperable.


WPAD poisoning
WPAD threat can potentially enables adversary to take control of others
proxy settings and retrieve users credentials for that proxy. To prevent
this threat, administrators could create a DNS entry for WPAD tha
points to corporate proxy server or they can also disable AutoDetect
proxy settings on IE clients altogether using GPO.
Security of network
Identify wireless AP
network segregation.
T186 Insecure network
segregation
Network subnetting and VLAN implementation should be deployed
securely. For example, servers VLAN should be differentiated with users'
VLAN and guests' VLAN to avoid users and guest from intercepting
communications to/from servers. VLAN deployment should minimize the
risk of MITM or relay attack (of important/sensitive communication traffic).
Such attack could be perform by using, for example, ARP spoofing.
Management ports for servers should also be accessible for authorized
personnel only.

T187 Perform network
reconnaissance/scanning.
Adversary uses commercial or free software to scan organizational
perimeters to obtain a better understanding of the information technology
infrastructure and improve the ability to launch successful attacks.

T188 Perform network sniffing of
exposed networks.
Adversary with access to exposed wired or wireless data channels used
to transmit information uses network sniffing to identify components,
resources, and protections.

T189
Insert malicious scanning
devices (e.g., wireless
sniffers) inside facilities.
Adversary uses postal service or other commercial delivery services to
deliver to organizational room a device that is able to scan wireless
communications accessible from within the room and then wirelessly
transmit information back to adversary.
Review whether there are
secure network
configurations documents
for network devices (such
as firewalls, routers, and
switches).
T190 Insecure deployment of
network devices
Network devices should be deployed securely. Network devices
documentation should be created, followed, and updated regularly to
ensure correct standard in network devices deployment.
Identify whether network
ports, protocols, and
services are limited and
controlled.
T191
Minimizing surface attack
Surface attack should be minimized to mitigate attack vectors. Ports,
protocols, and services should be deployed only when they are needed.
Organization could perform port and service scanning, as part of regular
vulnerability assessment, to confirm whether only needed ports,
protocols, and services are deployed in the network.
Identify network
segmentation /
segregation.
T192 Insecure network
segregation
Network subnetting and VLAN implementation should be deployed
securely. For example, servers VLAN should be differentiated with users'
VLAN and guests' VLAN to avoid users and guest from intercepting
communications to/from servers. VLAN deployment should minimize the
risk of MITM or relay attack (of important/sensitive communication traffic).
Such attack could be perform by using, for example, ARP spoofing.
Management ports for servers should also be accessible for authorized
personnel only.

T193 Perform network
reconnaissance/scanning.
Adversary uses commercial or free software to scan organizational
perimeters to obtain a better understanding of the information technology
infrastructure and improve the ability to launch successful attacks.

T194
Perform network sniffing of
exposed networks.
Adversary with access to exposed wired or wireless data channels used
to transmit information, uses network sniffing to identify components,
resources, and protections.
Identify the use of
network based intrusion
detection / prevention
system.
T195 Implementation of IDS /
IPS
Implementation of IPS / IDS could bring attack risks to minimum level if
configured correctly. A lot of network based or exploit based attacks
could be prevented by implementing IPS.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 130 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T196 Perform network
reconnaissance/scanning.
Adversary uses commercial or free software to scan organizational
perimeters to obtain a better understanding of the information technology
infrastructure and improve the ability to launch successful attacks.

T197 Perform network sniffing of
exposed networks.
Adversary with access to exposed wired or wireless data channels used
to transmit information uses network sniffing to identify components,
resources, and protections.

T198
Deliver known malware to
internal organizational
information systems (e.g.,
virus via email).
Adversary uses common delivery mechanisms (e.g., email) to
install/insert known malware (e. g., malware whose existence is known)
into organizational information systems.

T199
Deliver modified malware
to internal organizational
information systems.
Adversary uses more sophisticated delivery mechanisms than email
(e.g., web traffic, instant messaging, FTP) to deliver malware and
possibly modifications of known malware to gain access to internal
organizational information systems.
Identify the use of
website blacklisting in the
proxy.
T200 Insecure users daily
activities
Users daily activities such as browsing to the Internet, copying files
to/from USB, playing CD/DVD media could bring intentional/unintentional
risk to the network. Virus or malware could be unintentionally brought to
organization's network by unsuspecting users.

T201 Perform malware-directed
internal reconnaissance.
Adversary uses malware installed inside the organizational perimeter to
identify targets of opportunity. Because the scanning, probing, or
observation does not cross the perimeter, it is not detected by externally
placed intrusion detection systems.

T202 Craft phishing attacks
targetted for internal users
Adversary counterfeits communications from a legitimate/trustworthy
source to acquire sensitive information such as usernames, passwords,
or SSNs. Typical attacks occur via email, instant messaging, or
comparable means; commonly directing users to websites that appear to
be legitimate sites, while actually stealing the entered information.

T203
Deliver known malware to
internal organizational
information systems (e.g.,
virus via email).
Adversary uses common delivery mechanisms (e.g., email) to
install/insert known malware (e. g., malware whose existence is known)
into organizational information systems.

T204
Deliver modified malware
to internal organizational
information systems.
Adversary uses more sophisticated delivery mechanisms than email
(e.g., web traffic, instant messaging, FTP) to deliver malware and
possibly modifications of known malware to gain access to internal
organizational information systems.
Determine if the cabling
rooms and otjer ethernet
cable connections are
locked with limited
access and the access
are logged.
T205 Insecure physical data
center
Data centers, cabling cabinets, and switches cabinet should be deployed
securely, e.g. using locks or biometric devices, to prevent unauthorized
access to both physical and logical network environment.

T206 Perform network
reconnaissance/scanning.
Adversary uses commercial or free software to scan organizational
perimeters to obtain a better understanding of the information technology
infrastructure and improve the ability to launch successful attacks.

T207 Perform network sniffing of
exposed networks.
Adversary with access to exposed wired or wireless data channels used
to transmit information, uses network sniffing to identify components,
resources, and protections.

T208
Install general-purpose
sniffers on organization-
controlled information
systems or networks.
Adversary installs sniffing software onto internal organizational
information systems or networks.
Determine if
management ports of
domain controllers and
servers (RDP, SSH) are
connected to a dedicated
management network
(segmented from other
networks and only admin
workstations can connect
to them).
T209 Insecure network
segregation
Network subnetting and VLAN implementation shoiuld be deployed
securely. For example, servers VLAN should be differentiated with users'
VLAN and guests' VLAN to avoid users and guest from intercepting
communications to/from servers. VLAN deployment should minimize the
risk of MITM or relay attack (of important/sensitive communication traffic).
Such attack could be perform by using, for example, ARP spoofing.
Management ports for servers should also be accessible for authorized
personnel only.

T210 Perform network
reconnaissance/scanning.
Adversary uses commercial or free software to scan organizational
perimeters to obtain a better understanding of the information technology
infrastructure and improve the ability to launch successful attacks.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 131 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description

T211 Perform network sniffing of
exposed networks.
Adversary with access to exposed wired or wireless data channels used
to transmit information, uses network sniffing to identify components,
resources, and protections.
Security of DC


Determine if all DCs have
already the latest security
patches / service packs.
T212
Incomplete patch threat
Patches deployment should be complete and uniform throughtout AD
infrastructure. There should be patch management that control which
patch should be deployed and when. Administrators should also check
patch reporting console regularly and implement patches on computers
that lack of them.
Identity if there are
secure configuration
documentations or
procedures for deploying
DC.
T213 Lack of basic security
hardening
Servers and workstations, and all computers member of AD, should have
basic level of hardening. There should also hardening documentation that
describe the hardening process and what should be done to achieve a
good hardening standard as required by the organization. Hardening
usually includes disabling unrequired applications or services and
patching process before deploying servers or workstations.

T214 Incorrect configuration of
anti-virus
Anti-virus should be correctly configured. Correct configuration of anti-
virus includes uniformly deployed of anti-virus software throughout AD
environment (all AD computer members must have anti-virus deployed),
antivirus software could not be able to be disabled or removed even by
administrators, automatic update of signature files, and always up-to-date
antivirus database and application.

T215
Incomplete patch threat
Patches deployment should be complete and uniform throughout AD
infrastructure. There should be patch management that control which
patch should be deployed and when. Administrators should also check
patch reporting console regularly and implement patches on computers
that lack of them.

T216 Installation of unauthorized
applications
A whitelist of applications that can be installed should be identified,
documented and followed. This minimize the risk of security breach
through unauthorized applications.
Check whether DC is
placed in a secure
physical facility.
T217 Insecure physical data
center
Data centers, cabling cabinets, and switches cabinet should be deployed
securely, e.g. using locks or biometric devices, to prevent unauthorized
access to both physical and logical network environment.
Identify correct
deployment of anti-virus
and anti-malware
software on DC (check if
antivirus software has
been installed, determine
if antivirus software can
be disabled or removed,
check if the signature
files are updated
regularly).
T218 Incorrect configuration of
anti-virus
Anti-virus should be correctly configured. Correct configuration of anti-
virus includes uniformly deployed of anti-virus software throughout AD
environment (all AD computer members must have anti-virus deployed),
antivirus software could not be able to be disabled or removed even by
administrators, automatic update of signature files, and always up-to-date
antivirus database and application.
Identify whether DC runs
only essential services or
features.
T219
Minimizing surface attack
Surface attack should be minimized to mitigate attack vectors. Ports,
protocols, and services should be deployed only when they are needed.
Organization could perform port and service scanning, as part of regular
vulnerability assessment, to confirm whether only needed ports,
protocols, and services are deployed in the network.

T220
Lack of basic security
hardening
Servers and workstations, and all computers member of AD, should have
basic level of hardening. There should also hardening documentation that
describe the hardening process and what should be done to achieve a
good hardening standard as required by the organization. Hardening
usually includes disabling unrequired applications or services and
patching process before deploying servers or workstations.
Determine whether only
authorized personnel are
allowed to accessed DC
physically.
T221 Insecure physical data
center
Data centers, cabling cabinets, and switches cabinet should be deployed
securely, e.g. using locks or biometric devices, to prevent unauthorized
access to both physical and logical network environment.
Determine if DC is using
a backup power supply
(UPS).
T222 Lack of backup power
supply
Lack of UPS or similar power supply backup could present availability
problem for the AD. Integrity of AD system and DC's OS could also be
violated if UPS is not present.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 132 of 161




Aldo Elam Majiah

AD
Characterization
Threat
ID Threat events Threat description
Determine if DC can be
booted using alternative
OS.
T223 Boot using alternative OS
threat
DC and computer member of AD should be protected from portable
bootable media via USB or CD/DVD player. If an attacker could boot a
computer member from bootable media, he/she could extract password
hashes from computer's SAM database and crack it using a password
cracker program. If this attack is performed on DC, the attacker could
gain access to all password hashes of all users in the domain.
Determine if DC is using
a secure out-of-band
management network.
T224 Insecure network
segregation
Network subnetting and VLAN implementation should be deployed
securely. For example, servers VLAN should be differentiated with users'
VLAN and guests' VLAN to avoid users and guest from intercepting
communications to/from servers. VLAN deployment should minimize the
risk of MITM or relay attack (of important/sensitive communication traffic).
Such attack could be performed by using, for example, ARP spoofing.
Management ports for servers should also be accessible for authorized
personnel only.




Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 133 of 161




Aldo Elam Majiah

Appendix 4: Vulnerability Identification Table
Threat ID Vulnerability detected / identified
AD design & boundary
T1 There is no forest and domain structure threat since the domain is only single domain, single forest.
T2 There is no forest and domain structure threat since the domain is only single domain, single forest.
T3 There is no trust related threat since the domain is only single domain, single forest.
T4 There is no trust related threat since the domain is only single domain, single forest.
T5 Documentations on AD are not available, threat is imminent.
T6 There is no administrative boundary threat since the domain is only single domain, single forest.
AD management
T7 The operating system of the DC is 2008 while forest and domain functional level is 2003.
T8 There is only one DC without secondary domain controllers. All FSMO roles have availability issues.
T9 Documentations on AD are not available, threat is imminent.
T10 Administrators will not be able to effectively deploy applications / scripts / policies to selected computers since
there is no OU for computers (for example for deploying certain security configurations to all computers in the
public library).
T11 Administrators will not be able to effectively deploy applications / scripts / policies to selected security groups
since security groups are not heavily used.
T12 Administrators seem too occupied with helpdesk work and spend little time in managing AD.
T13 Documentations on AD are not available, threat is imminent.
T14 There is no control on high privilege account threat. On the penetration testing, the pen-tester was able to get
account of a domain admin.
T15 There is no delegation of tasks to groups / accounts. Daily administrative tasks were done using domain admin
privilege, which is very dangerous. On the penetration testing, the pen-tester was able to get account of a
domain admin.
T16 There is no separation of daily accounts and high privilege domain accounts for the administrators.
Administrators were doing daily tasks such as browsing and performing office related tasks using accounts that
have domain admin privilege.
T17 The passwords for local administrator accounts are all the same throughout the domain. During penetration
testing, pen-tester was able to acquired one of the desktop's local administrator account and then it turns out
that all computers in the domain are using the same passwords.
T18 There is no delegation of tasks to groups / accounts. Daily administrative tasks were done using domain admin
privilege, which is very dangerous. On the penetration testing, the pen-tester was able to get account of a
domain admin.
T19 Documentations on AD are not available, threat is imminent.
T20 The organization does not utilize log monitoring software. AD logs are also not monitored; pen-tester was able
to acquired high privilege domain admin accounts without being detected by administrators.
T21 The operating system of the DC is 2008 while forest and domain functional level is 2003.
T22 There is only one DC without secondary domain controllers. All FSMO roles have availability issues. There is
only one DC in the only site of the domain: default-first-name-site.
T23 AD is not backed up. There is no procedure for backing up AD and there is no implementation of AD backup
either.
T24 AD is not backed up. There is no procedure for backing up AD and there is no implementation of AD backup
either.
T25 HR has procedures for recruiting; the organization's vicinity is protected by security guards. Guests have to be
registered to enter the organization.
T26 HR has procedures for recruiting; the organization's vicinity is protected by security guards. Guests have to be
registered to enter the organization.
Policy implementation
T27 Administrators will not be able to effectively deploy applications / scripts / policies to selected computers since
there is no OU for computers (for example for deploying certain security configurations to all computers in the
public library).
T28 Password policies were not adequately implemented. Minimum password length was 3 characters, password
complexity was not enabled, and stored password using reversible encryption was also not set. From pen-
testing report, it was discovered that:
Passwords were the same as the usernames: 75 instances.
233 domain users were using 123 as the password of their accounts.
6 domain users were using 1234 as the password of their accounts.
4 domain users were using 12345 as the password of their accounts.
3 domain users were using 123456789 as the password of their accounts.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 134 of 161




Aldo Elam Majiah

Threat ID Vulnerability detected / identified
2 domain users were using 12345678 as the password of their accounts.
3 domain users were using password as the password of their accounts.
366 domain users were using 4 character password or less than 4 characters.
T29 The account lockout threshold is set to 0, which means all domain accounts are susceptible to mass account
lockout. A hacker could launch a brute force attack and lock all accounts on AD. And administrators will enable
these locked accounts one by one.
T30 Audit policy was not implemented.
T31 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T32 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T33 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T34 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T35 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T36 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T37 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T38 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T39 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T40 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T41 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T42 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T43 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T44 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T45 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T46 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T47 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T48 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T49 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T50 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T51 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T52 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T53 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T54 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T55 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T56 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T57 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T58 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 135 of 161




Aldo Elam Majiah

Threat ID Vulnerability detected / identified
T59 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T60 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T61 This policy item is not implemented. None of user right assignments policies were implemented to domain
computers.
T62 Local passwords from AD computer members are still saved in LM hash format. And so are AD users passwords
saved in DC. During penetration testing, pen tester was able to found out local administrator password of AD
computer members and crack 543 out of 808 domain users in less than 2 days of cracking process.
T63 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T64 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T65 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T66 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T67 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T68 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T69 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T70 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T71 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T72 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T73 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T74 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T75 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T76 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T77 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T78 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T79 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T80 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T81 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T82 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T83 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T84 Local passwords from AD computer members are still saved in LM hash format. And so are AD users passwords
saved in DC. During penetration testing, pen tester was able to found out local administrator password of AD
computer members and crack 543 out of 808 domain users in less than 2 days of cracking process.
T85 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T86 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T87 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T88 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T89 This policy item is not implemented. None of security options policies were implemented to domain
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 136 of 161




Aldo Elam Majiah

Threat ID Vulnerability detected / identified
computers.
T90 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T91 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T92 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T93 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T94 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T95 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T96 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T97 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T98 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T99 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T100 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T101 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T102 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T103 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T104 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T105 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T106 This policy item is not implemented. None of security options policies were implemented to domain
computers.
T107 Log monitoring is not enabled throughout domain. Log sizes were set to its default value.
Security of AD computer members
T108 Incomplete OS patches are the main problem in the domain. Six critical patches related to the following
Microsoft patches: MS11-030 is missing in 8 computers, MS09-001 in 5 computers, MS08-067 in 3 computers,
MS06-040 in 2 computers, MS05-027 in and MS09-050 is missing in 1 computer.
T109 There is not any list about which application that can be installed in users' workstations and servers.
T110 The likelihood of this threat is highly unlikely due to its complexity.
T111 There is no control on high privilege account threat. On the penetration testing, the pen-tester was able to get
account of a domain admin.
T112 The organization does not have policy / standard for basic security hardening.
T113 Most of the anti-virus programs were deployed correctly (antivirus software could not be able to be disabled
or removed even by administrators, automatic update of signature files, and always up-to-date antivirus
database and application). Yet, several workstations does not have anti-virus or the anti-virus can be disabled
without a password.
T114 Incomplete OS patches are the main problem in the domain. Six critical patches related to the following
Microsoft patches: MS11-030 is missing in 8 computers, MS09-001 in 5 computers, MS08-067 in 3 computers,
MS06-040 in 2 computers, MS05-027 in and MS09-050 is missing in 1 computer.
T115 There is not any list about which application that can be installed in users' workstations and servers.
T116 Most of the anti-virus programs were deployed correctly (antivirus software could not be able to be disabled
or removed even by administrators, automatic update of signature files, and always up-to-date antivirus
database and application). Yet, several workstations does not have anti-virus or the anti-virus can be disabled
without a password.
T117 All computers in the domain (including DC and computers in public area, such as library) can be booted using
alternative OS. This enables the pen-tester to get hash passwords of a local public computer and crack the
passwords.
T118 Portable media was not controlled. Data theft is possible. But data in the domain in not important (no data
about salary, for example)
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 137 of 161




Aldo Elam Majiah

Threat ID Vulnerability detected / identified
T119 It is highly unlikely there will be adversaries that perform such threat. The premise is guarded by security
guards and all guests are controlled.
T120 It is highly unlikely there will be adversaries that perform such threat. The premise is guarded by security
guards and all guests are controlled.
T121 The organization does not have regular vulnerability assessment, and it also never perform vulnerability
assessment prior to this pen-test project.
T122 AD is not backed up. There is no procedure for backing up AD and there is no implementation of AD backup
either.
T123 Some domain computers (workstation or servers) have their firewall up and running. But almost all of the
domain computers do not have their firewall enabled and configured.
T124 There has never been users' awareness or training on IT security.
T125 Local passwords from AD computer members are still saved in LM hash format. And so are AD users passwords
saved in DC. During penetration testing, pen tester was able to found out local administrator password of AD
computer members and crack 543 out of 808 domain users in less than 2 days of cracking process.
T126 From helpdesk logs, pen-tester found out that users are sometimes given local administrator access when
she/he cannot logon to domain.
T127 It is highly unlikely there will be adversaries that perform such threat. The premise is guarded by security
guards and all guests are controlled.
T128 All public facing servers are managed by vendor in a collocation program. None of the public-facing application
connects directly to internal organization.
T129 There is only one location in the premise. No VPN access or other remote access to other location.
T130 Mobile systems are not allowed access to AD domain. Furthermore, there is not any outside system that
connects back to the organization.
T131 A recently discovered exploit needs expertise to be launch. It is unlikely internal personnel choose to perform
such threat because there are still many other simple security holes that can be exploited.
T132 During penetration testing, pen-tester was able to successfully launch several exploits on Windows OS to gain
access to several workstations.
T133 A recently discovered exploit needs expertise to be launch. It is unlikely internal personnel choose to perform
such threat because there are still many other simple security holes that can be exploited.
T134 It is unlikely adversaries choose to perform such threat because there are still many other simple security
holes that can be exploited.
T135 All computers in the domain (including DC and computers in public area, such as library) can be booted using
alternative OS. This enables the pen-tester to get hash passwords of a local public computer and crack the
passwords.
T136 There is only one location in the premise. No VPN access or other remote access to other location. Only
teachers could perform such attack as they bring their laptops home, and it is unlikely that teachers will do
such attack as they are highly filtered during recruitment process.
T137 Only staffs could perform such attack as they bring their laptops home, and it is unlikely that staffs will do such
attack as they are highly filtered during recruitment process.
T138 It is unlikely adversaries choose to perform such threat because there are still many other simple security
holes that can be exploited.
T139 As the AD is not connected to mission-critical information system (such as payroll system), it is unlikely that
this threat occurs.
T140 It is possible to perform interception as demonstrated during pen-test. The organization still operates insecure
protocols hence ease the implementation of interception attacks.
T141 It is highly likely there will be adversaries that conduct such attack because the adversaries must be near or
inside the premise. The premise is guarded by security guards and all guests are controlled.
T142 There is no policy governing which ports, protocols, or services are authorized.
T143 All public facing servers are managed by vendor in a collocation program. None of the public-facing application
connects directly to internal organization. Security of the public facing servers are managed by partner
organization
T144 All public facing servers are managed by vendor in a collocation program. None of the public-facing application
connects directly to internal organization. Security of the public facing servers are managed by partner
organization
T145 All public facing servers are managed by vendor in a collocation program. None of the public-facing application
connects directly to internal organization. Security of the public facing servers are managed by partner
organization
T146 All public facing servers are managed by vendor in a collocation program. None of the public-facing application
connects directly to internal organization. Security of the public facing servers are managed by partner
organization
T147 It is highly unlikely there will be adversaries that perform such threat. The premise is guarded by security
guards and all guests are controlled.
T148 It is highly unlikely there will be adversaries that perform such threat. The premise is guarded by security
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 138 of 161




Aldo Elam Majiah

Threat ID Vulnerability detected / identified
guards and all guests are controlled.
T149 During penetration testing, pen-tester was able to successfully launch brute force attack on domain controllers
and acquired a weak password of a domain admin (highest privilege account on the AD).
T150 A recently discovered exploit needs expertise to be launch. It is unlikely internal personnel choose to perform
such threat because there are still many other simple security holes that can be exploited.
T151 There is only one location in the premise. No VPN access or other remote access to other location. Only
teachers could perform such attack as they bring their laptops home, and it is unlikely that teachers will do
such attack as they are highly filtered during recruitment process.
T152 Pen-tester performed such attack undetected during penetration testing.
T153 Adversaries could gain information from social media such as LinkedIn and Facebook as most of the staffs,
teachers, and students have their own social media.
T154 Adversaries could gain information from social media such as LinkedIn and Facebook as most of the staffs,
teachers, and students have their own social media.
T155 Personal owned devices are allowed but cannot connect directly to AD. Adversaries that launched such attack
may target personal information (credit cards, internet banking credential) not to get inside the AD of the
organization.
T156 Personal owned devices are allowed but cannot connect directly to AD. Adversaries that launched such attack
may target personal information (credit cards, internet banking credential) not to get inside the AD of the
organization.
T157 This threat, even though possible, is unlikely to be directed to AD of the organization.
T158 It is highly unlikely there will be internal adversaries that perform such threat. The premise is guarded by
security guards and all guests are controlled, hence external adversaries are also not very possible to launch
such attack.
T159 This threat could be possible, but the impact is minimum since publicly accessible information was handled by
third party (partner).
T160 It is highly unlikely there will be internal adversaries that perform such threat. The premise is guarded by
security guards and all guests are controlled, hence external adversaries are also not very possible to launch
such attack.
T161 It is highly unlikely there will be internal adversaries that perform such threat. The premise is guarded by
security guards and all guests are controlled, hence external adversaries are also not very possible to launch
such attack.
T162 Adversaries could gain information from social media such as LinkedIn and Facebook as most of the staffs,
teachers, and students have their own social media.
T163 Adversaries could gain information from social media such as LinkedIn and Facebook as most of the staffs,
teachers, and students have their own social media.
T164 It is highly likely there will be adversaries that conduct such attack because the adversaries must be near or
inside the premise. The premise is guarded by security guards and all guests are controlled.
T165 During penetration testing, pen-tester was able to get unauthorized access to all domain computers via
compromising AD. It is likely that adversaries will be able to do the same.
T166 During pen-test, several sensitive information can be acquired from public websites, including traffic
information to/and from the organization.
T167 Laptop is protected by passwords but the BIOS are not password protected. Adversary could boot the laptop
and steal data using alternative OS booting.
T168 Only internal staffs and students could perform such attack as they bring their laptops home, and it is unlikely
that they will do such attack.
T169 Currently the organization does not have classification of information. The attack is possible, for example due
to negligence.
T170 Currently the organization does not have classification of information. The attack is possible, for example due
to negligence.
T171 During penetration testing, pen-tester found account used to install software in computer with domain admin
privilege. This account does not bind to any username so no one is accountable for it. Such account should not
exist.
T172 This threat is unlikely to affect AD.
T173 This threat is unlikely to affect AD. Hardware in the premises was less than 3 years old.
T174 There has never been major earthquake in the city.
T175 The organization has their own anti-fire utilities.
T176 The organization does not have a backup facility.
T177 There has never been flood in the vicinity
T178 The organization does not have a backup facility.
T179 There has never been a hurricane in the country.
T180 The organization does not have a backup facility.
T181 Hardware in the organization is relatively new, less than 3 years of age. Resource depletion is unlikely to
happen.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 139 of 161




Aldo Elam Majiah

Threat ID Vulnerability detected / identified
T182 The organization used much free software with little or no support.
T183 Hardware in the organization is relatively new, less than 3 years of age. Hardware error is possible but rare.
T184 Hardware in the organization is relatively new, less than 3 years of age. Hardware error is possible but rare.
T185 There has never been a windstorm/tornado in the country.
Security of network
T186 The network is not segregated at all. Users from public areas and Wireless users can gain access to servers or
AD domain as the VLAN is only one.
T187 Pen-tester performed such attack undetected during penetration testing. It went undetected.
T188 Pen-tester performed such attack undetected during penetration testing of the organization's wireless
network. It went undetected.
T189 It is possible although unlikely an adversary could perform such attack. To perform such attack the adversaries
must first goes into the organization and passing the security guards in the premise.
T190 There is no document for deploying network devices but pen-tester did not find unsecure network devices
during penetration testing.
T191 Ports, protocols, and services are not controlled. This enables a wide surface attack. Services that are not
necessary should not be installed.
T192 The network is not segregated at all. Users from public areas and Wireless users can gain access to servers or
AD domain as the VLAN is only one.
T193 Pen-tester performed such attack undetected during penetration testing. It went undetected.
T194 Pen-tester performed such attack undetected during penetration testing of the organization's wireless
network. It went undetected.
T195 No IDS or IPS deployed in the network.
T196 Pen-tester performed such attack undetected during penetration testing. It went undetected.
T197 Pen-tester performed such attack undetected during penetration testing of the organization's wireless
network. It went undetected.
T198 Anti-virus software was deployed correctly in almost all users' computer. This minimizes the impact of a virus
spread.
T199 Anti-virus software was deployed correctly in almost all users' computer. This minimizes the impact of a
malware spread.
T200 There has never been users' awareness or training on IT security.
T201 Anti-virus software was deployed correctly in almost all users' computer. This minimizes the impact of a
malware spread.
T202 Anti-virus software was deployed correctly in almost all users' computer. This minimizes the impact of a
malware spread. But users have never been trained in security awareness. This threat is not directly related to
AD since the email address was not based on AD.
T203 Anti-virus software was deployed correctly in almost all users' computer. This minimizes the impact of a
malware spread.
T204 Anti-virus software was deployed correctly in almost all users' computer. This minimizes the impact of a
malware spread.
T205 Too many personnel are allowed to access data center. In/out logs are not managed. Data center is not
protected by biometric device but by a key instead.
T206 Pen-tester performed such attack undetected during penetration testing. It went undetected.
T207 Pen-tester performed such attack undetected during penetration testing of the organization's wireless
network. It went undetected.
T208 It is possible to install a sniffer in the network since there are many public areas with unprotected Ethernet
outlet.
T209 The network is not segregated at all. Users from public areas and Wireless users can gain access to servers or
AD domain as the VLAN is only one.
T210 Pen-tester performed such attack undetected during penetration testing. It went undetected.
T211 Pen-tester performed such attack undetected during penetration testing of the organization's wireless
network. It went undetected.
Security of DC
T212 DC was well patched.
T213 The organization does not have policy / standard for basic security hardening. There were unnecessary
applications / functions that are not supposed to be installed on the DC, such as file server, web server, firebird
database.
T214 The DC has anti-virus software configured correctly (antivirus software could not be able to be disabled or
removed even by administrators, automatic update of signature files, and always up-to-date antivirus
database and application). Yet, several workstations does not have anti-virus or the anti-virus can be disabled
without a password.
T215 The DC has only MS12-020 patch missing (Microsoft Windows Remote Desktop Protocol Server Man-in-the-
Middle Weakness).
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 140 of 161




Aldo Elam Majiah

Threat ID Vulnerability detected / identified
T216 There is not any list about which application that can be installed in users' workstations and servers.
T217 Too many personnel are allowed to access data center. In/out logs are not managed. Data center is not
protected by biometric device but by a key instead.
T218 Most of the anti-virus programs were deployed correctly (antivirus software could not be able to be disabled
or removed even by administrators, automatic update of signature files, and always up-to-date antivirus
database and application). Yet, several workstations does not have anti-virus or the anti-virus can be disabled
without a password.
T219 Ports, protocols, and services are not controlled. This enables a wide surface attack. Services that are not
directly related to AD should not be installed on the DC. The management ports on the DC should be
accessible by authorized personnel only.
T220 The organization does not have policy / standard for basic security hardening. But the DC was patched and
hardened by default domain controller policy.
T221 Too many personnel are allowed to access data center. In/out logs are not managed. Data center is not
protected by biometric device but by a key instead.
T222 UPS was present and standby to give backup power supply when necessary.
T223 All computers in the domain (including DC and computers in public area, such as library) can be booted using
alternative OS. This enables the pen-tester to get hash passwords of a local public computer and crack the
passwords.
T224 The management ports on the can be accessed by all users. MITM attacks are eminent.





Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 141 of 161




Aldo Elam Majiah

Appendix 5: Threat Risk-Level and Countermeasures
ID
threat
Likelihood
of event
initiation
or
occurrence
Likelihood
of threat
event
resulting
in impact
Likelihood Impact Risk Countermeasure recommendation
AD design & boundary
T1 VERY LOW VERY LOW VERY LOW HIGH LOW No countermeasure necessary.
T2 VERY LOW VERY LOW VERY LOW HIGH LOW No countermeasure necessary.
T3 VERY LOW VERY LOW VERY LOW HIGH LOW No countermeasure necessary.
T4 VERY LOW VERY LOW VERY LOW HIGH LOW No countermeasure necessary.
T5 HIGH MODERATE MODERATE HIGH MODERATE Create documentation on AD; the document
should include deployment, configuration,
structure, and policy guide. And it should be
approved by management and controlled.
T6 VERY LOW VERY LOW VERY LOW VERY LOW VERY LOW No countermeasure necessary.
AD management
T7 MODERATE MODERATE MODERATE MODERATE MODERATE Upgrade domain and forest functional level to
highest level possible to access more secure
AD domain configuration.
T8 HIGH HIGH HIGH HIGH HIGH Create secondary domain controller.
T9 HIGH MODERATE MODERATE HIGH MODERATE Create documentation on AD; the document
should include deployment, configuration,
structure, and policy guide. And it should be
approved by management and controlled.
T10 MODERATE MODERATE MODERATE MODERATE MODERATE Create and utilize computer-based OU in
accordance to their computer functions, for
example server OU, teachers' workstation
OU, library computers OU, etc.
T11 LOW LOW LOW LOW LOW Create and utilize security groups when
necessary.
T12 HIGH LOW MODERATE LOW LOW Train AD administrators in Microsoft's
certification program related to AD.
T13 HIGH MODERATE MODERATE HIGH MODERATE Create documentation on AD; the document
should include deployment, configuration,
structure, and policy guide. And it should be
approved by management and controlled.
T14 HIGH HIGH HIGH VERY HIGH VERY HIGH Control the use of high privilege domain
account by limiting high privilege domain
admins to a minimum number.
T15 MODERATE HIGH MODERATE HIGH MODERATE Utilize the use of restricted group to groups /
accounts and minimize the use of domain
admins groups for performing daily tasks
T16 HIGH HIGH HIGH VERY HIGH VERY HIGH Create separate accounts to be used by
administrators. One for doing daily, office-
related, tasks and the other one is for
managing domain.
T17 HIGH HIGH HIGH HIGH HIGH Create a policy that states passwords for
domain or local accounts should be changed
every several days.
T18 MODERATE HIGH MODERATE HIGH MODERATE Utilize the use of restricted group to groups /
accounts and minimize the use of domain
admins groups for performing daily tasks
T19 HIGH MODERATE MODERATE HIGH MODERATE Create documentation on AD, the document
should include deployment, conugration,
structure, and policy guide. And it should be
approved by management and controlled.
T20 HIGH MODERATE MODERATE MODERATE MODERATE Utilize log monitoring software and perform
regular check on AD logs, specially on logon
attempts log events.
T21 MODERATE MODERATE MODERATE MODERATE MODERATE Upgrade domain and forest functional level to
highest level possible to access more secure
AD domain configuration.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 142 of 161




Aldo Elam Majiah

ID
threat
Likelihood
of event
initiation
or
occurrence
Likelihood
of threat
event
resulting
in impact
Likelihood Impact Risk Countermeasure recommendation
T22 HIGH HIGH HIGH HIGH HIGH Create secondary domain controller.
T23 MODERATE MODERATE MODERATE MODERATE MODERATE Perform regular backup on AD, create
documents on AD backup, and test the
backup result regularly.
T24 MODERATE MODERATE MODERATE MODERATE MODERATE Perform regular backup on AD, create
documents on AD backup, and test the
backup result regularly.
T25 MODERATE VERY LOW LOW MODERATE LOW Countermeasure is sufficient.
T26 MODERATE VERY LOW LOW MODERATE LOW Countermeasure is sufficient.
Policy implementation
T27 MODERATE MODERATE MODERATE MODERATE MODERATE Create and utilize computer-based OU in
accordance to their computer functiions, for
example server OU, teachers' workstation
OU, library computers OU, etc.
T28 HIGH VERY HIGH VERY HIGH HIGH HIGH Implement a more secure password policy for
domain users. Example of good password
policies are: password history must be
enforced to at least 10 times, maximum and
minimum password age are set to at least 30
days and 1 day respectively, minimum
password length are set to at least 8
character (preferable 9 if NTLM is still
enabled in computers member in AD),
password complexity must be set, and strore
password using reversible encryption must be
disabled.
T29 HIGH HIGH HIGH MODERATE MODERATE Implement better account lockout policy:For
example account lockout threshold should be
set to a minimum number such as 3 times, do
not set it to 0 time as it may trigger massive
account lockout if a bruteforce attack is
underway. Account lockout duration and
account reset counter should be set to a
agreeable amount of times defined by
organization, for example 30 minutes.
T30 MODERATE MODERATE MODERATE MODERATE MODERATE Implement a correct audit policy to help in
investigating a security incidents case.Which
part of audit policy that should be enabled
usually depends on the organization's policy.
At least audit of success and failure of
authentication of account logon events must
be enabled.
T31 LOW LOW LOW LOW LOW Implement this policy to the domain
prudently: Symbolic links threat
T32 LOW LOW LOW LOW LOW Implement this policy to the domain
prudently: Modification of object label
T33 VERY LOW LOW VERY LOW LOW VERY LOW Implement this policy to the domain
prudently: Creation of global objects
T34 MODERATE MODERATE MODERATE LOW LOW Implement this policy to the domain
prudently: Impersonation a client after
authentication
T35 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Deny log on through Terminal
Services
T36 VERY LOW LOW VERY LOW LOW VERY LOW Implement this policy to the domain
prudently: Perform volume maintenance
tasks
T37 LOW LOW LOW MODERATE LOW Implement this policy to the domain
prudently: Enable computer and user
accounts to be trusted for delegation
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 143 of 161




Aldo Elam Majiah

ID
threat
Likelihood
of event
initiation
or
occurrence
Likelihood
of threat
event
resulting
in impact
Likelihood Impact Risk Countermeasure recommendation
T38 VERY LOW LOW VERY LOW LOW VERY LOW Implement this policy to the domain
prudently: Synchronize directory service data
T39 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain
prudently: Deny logon locally
T40 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain
prudently: Deny log on as a service
T41 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain
prudently: Deny log on as a batch job
T42 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain
prudently: Deny access to this computer from
the network
T43 LOW VERY LOW VERY LOW LOW VERY LOW Implement this policy to the domain
prudently: Take ownership of files or other
objects
T44 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Shut down the system
T45 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain
prudently: Restore files and directories
T46 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Replace a process level token
T47 VERY LOW LOW VERY LOW LOW VERY LOW Implement this policy to the domain
prudently: Modify firmware environment
values
T48 MODERATE LOW LOW LOW LOW Implement this policy to the domain
prudently: Manage auditing and security log
T49 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Allow log on locally. Do not allow
users to logged on to servers.
T50 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain
prudently: Lock pages in memory
T51 MODERATE LOW LOW LOW LOW Implement this policy to the domain
prudently: Load and unload device drivers
T52 LOW VERY LOW VERY LOW LOW VERY LOW Implement this policy to the domain
prudently: Adjust memory quotas for a
process
T53 LOW VERY LOW VERY LOW LOW VERY LOW Implement this policy to the domain
prudently: Generate security audits
T54 LOW MODERATE LOW MODERATE LOW Force shutdown from a remote Implement
this policy to the domain prudently: system
T55 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain
prudently: Debug programs
T56 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Create a token object
T57 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain
prudently: Change the system time
T58 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Back up files and directories
T59 LOW MODERATE LOW LOW LOW Implement this policy to the domain
prudently: Add workstations to domain
T60 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain
prudently: Act as part of the operating system
T61 HIGH MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently:Access this computer from the
network. Do not assigned everyone value to
these settings.
T62 HIGH HIGH HIGH HIGH HIGH Implement this policy to the domain
prudently: Network security: Do not store
LAN Manager hash value on next password
change. This policy must be implemented
domain wide.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 144 of 161




Aldo Elam Majiah

ID
threat
Likelihood
of event
initiation
or
occurrence
Likelihood
of threat
event
resulting
in impact
Likelihood Impact Risk Countermeasure recommendation
T63 LOW VERY LOW VERY LOW LOW VERY LOW Implement this policy to the domain
prudently: Recovery console: Allow automatic
administrative logon
T64 LOW LOW LOW LOW LOW Implement this policy to the domain
prudently: Devices: Restrict CD-ROM access
to locally logged-on user only
T65 MODERATE HIGH MODERATE HIGH MODERATE Implement this policy to the domain
prudently: Interactive logon: Number of
previous logons to cache (in case domain
controller is not available)
T66 MODERATE MODERATE MODERATE LOW LOW Implement this policy to the domain
prudently: Interactive logon: Require Domain
Controller authentication to unlock
T67 MODERATE MODERATE MODERATE LOW LOW Implement this policy to the domain
prudently: User Account Control: Behavior of
the elevation prompt for administrators in
Admin Approval Mode
T68 MODERATE MODERATE MODERATE VERY LOW VERY LOW Implement this policy to the domain
prudently:
T69 HIGH MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Interactive logon: Do not require
CTRL+ALT+DEL
T70 LOW MODERATE LOW LOW LOW Implement this policy to the domain
prudently: Interactive logon: Do not display
last user name
T71 HIGH MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Interactive logon: Message text for
users attempting to log on
T72 MODERATE MODERATE MODERATE LOW LOW Implement this policy to the domain
prudently: Shutdown: Allow system to be
shut down without having to log on
T73 LOW LOW LOW LOW LOW Implement this policy to the domain
prudently: User Account Control: Only elevate
executables that are signed and validated
T74 LOW MODERATE LOW LOW LOW Implement this policy to the domain
prudently: System Cryptography: Force strong
key protection for user keys stored on the
computer
T75 HIGH MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Audit: Shut down system
immediately if unable to log security audits
T76 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain
prudently:
T77 MODERATE HIGH MODERATE HIGH MODERATE Implement this policy to the domain
prudently: Network access: Let Everyone
permissions apply to anonymous users
T78 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain
prudently: System cryptography: Use FIPS
compliant algorithms for encryption, hashing
and signing
T79 LOW VERY LOW VERY LOW MODERATE LOW Implement this policy to the domain
prudently: Network access: Sharing and
security model for local accounts
T80 LOW LOW LOW LOW LOW Implement this policy to the domain
prudently: Audit: Audit the use of Backup and
Restore privilege
T81 HIGH HIGH HIGH HIGH HIGH Implement this policy to the domain
prudently: Accounts: Limit local account use
of blank passwords to console logon only
T82 HIGH MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 145 of 161




Aldo Elam Majiah

ID
threat
Likelihood
of event
initiation
or
occurrence
Likelihood
of threat
event
resulting
in impact
Likelihood Impact Risk Countermeasure recommendation
prudently: Network security: LAN Manager
authentication level
T83 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently:
T84 HIGH HIGH HIGH HIGH HIGH Implement this policy to the domain
prudently: Network security: Do not store
LAN Manager hash value on next password
change. This policy must be implemented
domain wide.
T85 MODERATE LOW LOW LOW LOW Implement this policy to the domain
prudently: Network access: Do not allow
anonymous enumeration of SAM accounts
and shares
T86 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Network access: Do not allow
anonymous enumeration of SAM accounts
T87 LOW MODERATE LOW LOW LOW Implement this policy to the domain
prudently:
T88 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain
prudently: Shutdown: Clear virtual memory
pagefile
T89 LOW LOW LOW LOW LOW Implement this policy to the domain
prudently:
T90 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Microsoft network server: Digitally
sign communications (if client agrees)
T91 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Microsoft network server: Digitally
sign communications (always)
T92 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain
prudently: Microsoft network client: Send
unencrypted password to connect to third-
party SMB servers
T93 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Microsoft network client: Digitally
sign communications (if server agrees)
T94 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain
prudently: Microsoft network client: Digitally
sign communications (always)
T95 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain
prudently: Network security: LDAP client
signing requirements
T96 LOW LOW LOW LOW LOW Implement this policy to the domain
prudently: Domain member: Disable machine
account password changes
T97 MODERATE LOW LOW LOW LOW Implement this policy to the domain
prudently: Domain member: Digitally encrypt
or sign secure channel data (always)
T98 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain
prudently: Domain member: Require strong
(Windows 2000 or later) session key
T99 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain
prudently: Domain member: Digitally encrypt
secure channel data (when possible)
T100 MODERATE LOW LOW MODERATE LOW Implement this policy to the domain
prudently: Domain member: Digitally sign
secure channel data (when possible)
T101 LOW MODERATE LOW MODERATE LOW Implement this policy to the domain
prudently: Domain controller: LDAP server
signing requirements
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 146 of 161




Aldo Elam Majiah

ID
threat
Likelihood
of event
initiation
or
occurrence
Likelihood
of threat
event
resulting
in impact
Likelihood Impact Risk Countermeasure recommendation
T102 HIGH HIGH HIGH MODERATE MODERATE Implement this policy to the domain
prudently: Network access: Allow anonymous
SID/name translation
T103 LOW LOW LOW LOW LOW Implement this policy to the domain
prudently: Accounts: Rename guest account
T104 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Accounts: Rename administrator
account
T105 MODERATE HIGH MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Accounts: Guest account status.
Disabled guest accounts whenever possible.
T106 MODERATE MODERATE MODERATE MODERATE MODERATE Implement this policy to the domain
prudently: Accounts: Administrator account
status.
T107 MODERATE MODERATE MODERATE MODERATE MODERATE Add log size of, at least, security events.
Monitor all logs and events using a log
monitoring software.
Security of AD computer members
T108 HIGH HIGH HIGH VERY HIGH VERY HIGH Implement an automatic patch management
system. Monitor the patch management
system regularly to ensure all domain
computers are patched.
T109 MODERATE HIGH MODERATE MODERATE MODERATE Create a policy and standard about which
applications are permitted on workstations
and servers.
T110 VERY LOW LOW VERY LOW VERY LOW VERY LOW
T111 HIGH HIGH HIGH VERY HIGH VERY HIGH Control the use of high privilege domain
account by limiting high privilege domain
admins to a minimum number.
T112 HIGH HIGH HIGH HIGH HIGH Create a policy / standard for basic security
hardening for workstations and servers
deployment. Implement and control the
policy.
T113 MODERATE MODERATE MODERATE HIGH MODERATE Ensure that anti-virus were deployed
correctly to all domain computers.
T114 HIGH HIGH HIGH VERY HIGH VERY HIGH Implement an automatic patch management
system. Monitor the patch management
system regularly to ensure all domain
computers are patched.
T115 MODERATE HIGH MODERATE MODERATE MODERATE Create a policy and standard about which
applications are permitted on workstations
and servers.
T116 MODERATE MODERATE MODERATE HIGH MODERATE Ensure that anti-virus were deployed
correctly to all domain computers.
T117 MODERATE HIGH MODERATE MODERATE MODERATE Disable booting from portable / removeable
media from BIOS. Protect BIOS with
password.
T118 LOW LOW LOW MODERATE LOW
T119 LOW LOW LOW MODERATE LOW
T120 LOW LOW LOW MODERATE LOW
T121 MODERATE HIGH MODERATE MODERATE MODERATE Perform regular vulnerability assessment in
accordance to organization's policy (e.g. once
a year).
T122 MODERATE MODERATE MODERATE MODERATE MODERATE Perform regular backup on AD, create
documents on AD backup, and test the
backup result regularly.
T123 MODERATE HIGH MODERATE MODERATE MODERATE Enabled host-based firewall implementation
via GPO to ensure uniform implementation of
firewall throughout the domain.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 147 of 161




Aldo Elam Majiah

ID
threat
Likelihood
of event
initiation
or
occurrence
Likelihood
of threat
event
resulting
in impact
Likelihood Impact Risk Countermeasure recommendation
T124 HIGH MODERATE MODERATE MODERATE MODERATE Conduct users' awareness program or training
on IT security.
T125 HIGH HIGH HIGH HIGH HIGH Implement this policy to the domain
prudently: Network security: Do not store
LAN Manager hash value on next password
change. This policy must be implemented
domain wide.
T126 HIGH MODERATE MODERATE MODERATE MODERATE Conduct users' awareness program or training
on IT security.
T127 VERY LOW LOW VERY LOW LOW VERY LOW
T128 VERY LOW LOW VERY LOW MODERATE LOW
T129 VERY LOW LOW VERY LOW LOW VERY LOW
T130 VERY LOW LOW VERY LOW LOW VERY LOW
T131 VERY LOW LOW VERY LOW LOW VERY LOW
T132 HIGH HIGH HIGH HIGH HIGH
T133 VERY LOW LOW VERY LOW LOW VERY LOW
T134 VERY LOW LOW VERY LOW LOW VERY LOW
T135 MODERATE HIGH MODERATE MODERATE MODERATE Disable booting from portable / removeable
media from BIOS. Protect BIOS with
password.
T136 LOW LOW LOW LOW LOW
T137 LOW LOW LOW LOW LOW
T138 VERY LOW LOW VERY LOW LOW VERY LOW
T139 MODERATE VERY LOW LOW HIGH LOW
T140 MODERATE HIGH MODERATE HIGH MODERATE Disable insecure protocols and replace them
with their secure counterparts.
T141 VERY LOW LOW VERY LOW LOW VERY LOW
T142 MODERATE HIGH MODERATE HIGH MODERATE Disable insecure protocols and replace them
with their secure counterparts. Create
application whitelisting.
T143 MODERATE LOW LOW MODERATE LOW
T144 MODERATE LOW LOW MODERATE LOW
T145 MODERATE LOW LOW MODERATE LOW
T146 MODERATE LOW LOW MODERATE LOW
T147 LOW MODERATE LOW MODERATE LOW
T148 LOW MODERATE LOW MODERATE LOW
T149 MODERATE VERY HIGH HIGH HIGH HIGH Implement a more secure password policy for
domain users.
Implement also better account lockout policy.
T150 VERY LOW LOW VERY LOW LOW VERY LOW
T151 LOW LOW LOW LOW LOW
T152 VERY HIGH LOW MODERATE VERY HIGH HIGH Implement IDS / IPS for detecting such attack.
T153 HIGH MODERATE MODERATE MODERATE MODERATE Conduct users' awareness program or training
on IT security.
T154 HIGH MODERATE MODERATE MODERATE MODERATE Conduct users' awareness program or training
on IT security.
T155 LOW LOW LOW LOW LOW
T156 MODERATE LOW LOW LOW LOW
T157 VERY LOW LOW VERY LOW LOW VERY LOW
T158 LOW MODERATE LOW MODERATE LOW
T159 LOW LOW LOW MODERATE LOW
T160 LOW MODERATE LOW MODERATE LOW
T161 LOW MODERATE LOW MODERATE LOW
T162 HIGH MODERATE MODERATE MODERATE MODERATE Conduct users' awareness program or training
on IT security.
T163 HIGH MODERATE MODERATE MODERATE MODERATE Conduct users' awareness program or training
on IT security.
T164 VERY LOW LOW VERY LOW LOW VERY LOW
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 148 of 161




Aldo Elam Majiah

ID
threat
Likelihood
of event
initiation
or
occurrence
Likelihood
of threat
event
resulting
in impact
Likelihood Impact Risk Countermeasure recommendation
T165 MODERATE MODERATE MODERATE MODERATE MODERATE Create and implement IT policy. Include
acceptable use of workstations, internet,
email, etc.
T166 LOW HIGH MODERATE HIGH MODERATE Integrate security into SDLC of every software
development, including web applications.
T167 LOW HIGH MODERATE HIGH MODERATE Encrypt sensitive information.
T168 LOW LOW LOW LOW LOW
T169 HIGH MODERATE MODERATE MODERATE MODERATE Create and implement classifcation of
information and conduct users' awareness on
it.
T170 HIGH MODERATE MODERATE MODERATE MODERATE Create and implement classifcation of
information and conduct users' awareness on
it.
T171 MODERATE HIGH MODERATE VERY HIGH HIGH Control the use of high privilege domain
account by limiting high privilege domain
admins to a minimum number.
T172 VERY LOW LOW VERY LOW VERY LOW VERY LOW
T173 VERY LOW LOW VERY LOW LOW VERY LOW Replace hardware regularly, in accordance to
organization's policy.
T174 VERY LOW LOW VERY LOW LOW VERY LOW
T175 VERY LOW LOW VERY LOW MODERATE LOW
T176 VERY LOW VERY LOW VERY LOW VERY LOW VERY LOW
T177 VERY LOW LOW VERY LOW MODERATE LOW
T178 VERY LOW VERY LOW VERY LOW VERY LOW VERY LOW
T179 VERY LOW VERY LOW VERY LOW VERY LOW VERY LOW
T180 VERY LOW VERY LOW VERY LOW VERY LOW VERY LOW
T181 LOW LOW LOW LOW LOW
T182 LOW MODERATE LOW LOW LOW
T183 MODERATE LOW LOW LOW LOW
T184 MODERATE LOW LOW LOW LOW
T185 VERY LOW VERY LOW VERY LOW VERY LOW VERY LOW
Security of network
T186 HIGH HIGH HIGH HIGH HIGH Create a well segregated network. Server and
workstations should have separated VLAN.
Management network and out of band VLAN
should only be accessible for the
administrators.
T187 VERY HIGH LOW MODERATE HIGH MODERATE Implement IDS / IPS for detecting such attack.
T188 VERY HIGH LOW MODERATE HIGH MODERATE Implement IDS / IPS for detecting such attack.
T189 MODERATE LOW LOW LOW LOW
T190 LOW LOW LOW MODERATE LOW
T191 HIGH HIGH HIGH HIGH HIGH Perform regular vulnerability assessment in
accordance to organization's policy (e.g. once
a year) to identify unnecessary ports,
protocols, services.
Uninstall unnecessary ports and services.
Upgrade to secure protocols.
T192 HIGH HIGH HIGH HIGH HIGH Create a well segregated network. Server and
workstations should have separated VLAN.
Management network and out of band VLAN
should only be accessible for the
administrators.
T193 VERY HIGH LOW MODERATE MODERATE MODERATE Implement IDS / IPS for detecting such attack.
T194 VERY HIGH LOW MODERATE MODERATE MODERATE Implement IDS / IPS for detecting such attack.
T195 MODERATE MODERATE MODERATE HIGH MODERATE Implement IDS / IPS for detecting such attack.
T196 VERY HIGH LOW MODERATE MODERATE MODERATE Implement IDS / IPS for detecting such attack.
T197 VERY HIGH LOW MODERATE MODERATE MODERATE Implement IDS / IPS for detecting such attack.
T198 MODERATE LOW LOW LOW LOW
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 149 of 161




Aldo Elam Majiah

ID
threat
Likelihood
of event
initiation
or
occurrence
Likelihood
of threat
event
resulting
in impact
Likelihood Impact Risk Countermeasure recommendation
T199 MODERATE LOW LOW LOW LOW
T200 HIGH MODERATE MODERATE MODERATE MODERATE Conduct users' awareness program or training
on IT security.
T201 MODERATE LOW LOW LOW LOW
T202 MODERATE MODERATE MODERATE MODERATE MODERATE Conduct users' awareness program or training
on IT security.
T203 MODERATE LOW LOW LOW LOW
T204 MODERATE LOW LOW LOW LOW
T205 HIGH HIGH HIGH HIGH HIGH
T206 VERY HIGH LOW MODERATE MODERATE MODERATE Implement IDS / IPS for detecting such attack.
T207 VERY HIGH LOW MODERATE MODERATE MODERATE Implement IDS / IPS for detecting such attack.
T208 VERY HIGH LOW MODERATE MODERATE MODERATE
T209 HIGH HIGH HIGH HIGH HIGH Create a well segregated network. Server and
workstations should have separated VLAN.
Management network and out of band VLAN
should only be accessible for the
administrators.
T210 VERY HIGH LOW MODERATE MODERATE MODERATE Implement IDS / IPS for detecting such attack.
T211 VERY HIGH LOW MODERATE MODERATE MODERATE Implement IDS / IPS for detecting such attack.
Security of DC
T212 LOW LOW LOW LOW LOW
T213 HIGH MODERATE MODERATE HIGH MODERATE Create a policy / standard for basic security
hardening for workstations and servers
deployment. Implement and control the
policy.
T214 LOW LOW LOW HIGH LOW
T215 MODERATE MODERATE MODERATE MODERATE MODERATE Implement an automatic patch management
system. Monitor the patch management
system regularly to ensure all domain
computers are patched.
T216 MODERATE HIGH MODERATE MODERATE MODERATE Create a policy and standard about which
applications are permitted on workstations
and servers.
T217 HIGH HIGH HIGH HIGH HIGH Enable biometric-based locks and monitor
in/out logs.
T218 LOW LOW LOW HIGH LOW
T219 HIGH HIGH HIGH HIGH HIGH Create a well segregated network. Server and
workstations should have separated VLAN.
Management network and out of band VLAN
should only be accessible for the
administrators.
T220 LOW LOW LOW LOW LOW
T221 HIGH HIGH HIGH HIGH HIGH Enable biometric-based locks and monitor
in/out logs.
T222 VERY LOW MODERATE LOW MODERATE LOW
T223 MODERATE HIGH MODERATE MODERATE MODERATE Disable booting from portable / removeable
media from BIOS. Protect BIOS with
password.
T224 MODERATE MODERATE MODERATE MODERATE MODERATE Create a well segregated network. Server and
workstations should have separated VLAN.
Management network and out of band VLAN
should only be accessible for the
administrators.


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 150 of 161




Aldo Elam Majiah

Appendix 6: Experts Profiles
Identification Expertise
Expert 01 She works as solution architect in a Japanese-based system integrator company.
She has 4 years of experiences in infrastructure fields, AD, virtualization, and
network implementation. She was well versed in Cisco, Microsoft, and VMWare
solutions.
Certifications:
VMWare Certified Professional 4 & 5
HP AIS Network Infrastructure
MCITP Enterprise Administrator
Cisco Certified Network Associate
STS Symantec Backup Exec
Cisco Certified Design Associate
Expert 02 He has over 12 years of professional experience in positions as manager, IT
auditor, IT security consultant, senior system engineer, network administrator
supervisor, and system administrator.
Certifications:
Certified Information Systems Auditor (CISA)
Certified Information Security Manager (CISM)
Microsoft Certified Systems Engineer (MCSE)
ISO 27001 Lead Auditor
Expert 03 He has over 12 years of professional experience in information security field
and has been working on number penetration testing projects. He is currently
active in several projects: OWASP Indonesia; openSUSE Indonesia; DVWA Web
Applications. He also has published an international book on IT security: Kali
Linux Assuring Security by Penetration Testing.
Certifications:
CISSP - Certified Information Systems Security Professional
Symantec STS - Control Compliance Suite and Security Information Manager
ISO 27001 Lead Auditor
Expert 04 He has more than 5 years experience as technical consultant and delivers more
than 59 projects related with Windows infrastructure, VMWare
implementation, and Symantec solutions.
Certifications:
Certified Ethical Hacker
MCITP Microsoft Exchange
VCP (VMWare Certified Professional) for VMWare 5, 4, and 3
MCITP Enterprise Administrator
MCTS Windows Server Virtualization
MCITP Server Administrator
Sun Certified System Administrator
Expert 05 As a CTO of an IT security firm, he has over 15 years of information security
experience. He has delivered over 100 security consulting projects in Indonesia
for reputable enterprise and government institutions. He is also experienced in
conducting a security research and is an author of a several recognized security
white papers on Telecom Fraud, Bluetooth, web-application security etc. He is
also a frequent speaker on various regional security conferences.
Certification:
Certified Ethical Hacker
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 151 of 161




Aldo Elam Majiah

Identification Expertise
Expert 06 He has deep experience in network and information security for enterprise and
telecommunication for mobile operators. He also has delivered consulting
projects for enterprises and telco companies, including Wifi and web app
pentest, vulnerability assessment, network security architecture review, and
network system configuration review.
Certification:
CISSP (Certified Information System Security Professional)
CISA (Certified Information System Auditor)
ISO27001:2005 Lead Auditor
SANS-GCFW (GIAC Certified Firewall Analyst)
SANS-GCIH (GIAC Certified Incident Handling)
Foundstone RMTP (Risk Management Technical Professional)
ACSA (ArcSight Certified Security Analyst)
ACIA (ArcSight Certified Integrator/Administrator)
CCSP - Cisco Certified Security Professional


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 152 of 161




Aldo Elam Majiah

Appendix 7: Artifacts Evaluated by Experts
The first artifact to be evaluated by experts is AD risk assessment framework and AD
components.


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 153 of 161




Aldo Elam Majiah

The second artifact, security GPO, is the result of the risk assessment process on AD
components of the organization. Below is the security GPO.
Security_GPO
ComputerConfiguration(Enabled)
Policies
WindowsSettings
SecuritySettings
AccountPolicies/PasswordPolicy
Policy Setting
Enforcepasswordhistory 10passwordsremembered
Maximumpasswordage 30days
Minimumpasswordage 1days
Minimumpasswordlength 8characters
Passwordmustmeetcomplexityrequirements Enabled
Storepasswordsusingreversibleencryption Disabled
AccountPolicies/AccountLockoutPolicy
Policy Setting
Accountlockoutduration 30minutes
Accountlockoutthreshold 3invalidlogonattempts
Resetaccountlockoutcounterafter 30minutes
AccountPolicies/KerberosPolicy
Policy Setting
Enforceuserlogonrestrictions Enabled
Maximumlifetimeforserviceticket 600minutes
Maximumlifetimeforuserticket 10hours
Maximumlifetimeforuserticketrenewal 34days
Maximumtoleranceforcomputerclock
synchronization
5minutes
LocalPolicies/AuditPolicy
Policy Setting
Auditaccountlogonevents Success,Failure
Auditaccountmanagement Success,Failure
Auditdirectoryserviceaccess Failure
Auditlogonevents Success,Failure
Auditobjectaccess Failure
Auditpolicychange Success,Failure
Auditprivilegeuse Success,Failure
Auditprocesstracking Failure
Auditsystemevents Success,Failure
LocalPolicies/UserRightsAssignment
Policy Setting
Accessthiscomputerfromthenetwork BUILTIN\BackupOperators,BUILTIN\Administrators
Allowlogonlocally BUILTIN\BackupOperators,BUILTIN\Administrators
Backupfilesanddirectories BUILTIN\BackupOperators,BUILTIN\Administrators
Createatokenobject NTAUTHORITY\LOCALSERVICE
DenylogonthroughTerminalServices BUILTIN\Guests
Replaceaprocessleveltoken NTAUTHORITY\NETWORKSERVICE,NT
AUTHORITY\LOCALSERVICE
Shutdownthesystem BUILTIN\BackupOperators,BUILTIN\Administrators
LocalPolicies/SecurityOptions
Accounts
Policy Setting
Accounts:Administratoraccountstatus Enabled
Accounts:Guestaccountstatus Disabled
Accounts:Limitlocalaccountuseofblank
passwordstoconsolelogononly
Enabled
Accounts:Renameadministratoraccount "admorganizationname"
Audit
Policy Setting
Audit:Shutdownsystemimmediatelyifunableto
logsecurityaudits
Disabled
InteractiveLogon
Policy Setting
Interactivelogon:DonotrequireCTRL+ALT+DEL Disabled
Interactivelogon:Messagetextforusersattempting
tologon
Theinformationonthiscomputerandnetworkisthe
property,ofthisorganizationandisprotectedby
intellectualpropertyrights.,Youmustbeassigned
anaccountonthiscomputertoaccessinformation,
andareonlyallowedtoaccessinformationdefined
bythesystem,administrators.Youractivitieswillbe
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 154 of 161




Aldo Elam Majiah

monitored.
Interactivelogon:Messagetitleforusersattempting
tologon
"AuthorizedUseOnly!"
Interactivelogon:Numberofpreviouslogonsto
cache(incasedomaincontrollerisnotavailable)
2logons
MicrosoftNetworkClient
Policy Setting
Microsoftnetworkclient:Digitallysign
communications(always)
Enabled
Microsoftnetworkclient:Digitallysign
communications(ifserveragrees)
Enabled
MicrosoftNetworkServer
Policy Setting
Microsoftnetworkserver:Digitallysign
communications(always)
Enabled
Microsoftnetworkserver:Digitallysign
communications(ifclientagrees)
Enabled
NetworkAccess
Policy Setting
Networkaccess:AllowanonymousSID/Name
translation
Disabled
Networkaccess:Donotallowanonymous
enumerationofSAMaccounts
Enabled
Networkaccess:Donotallowanonymous
enumerationofSAMaccountsandshares
Enabled
Networkaccess:LetEveryonepermissionsapplyto
anonymoususers
Disabled
NetworkSecurity
Policy Setting
Networksecurity:DonotstoreLANManagerhash
valueonnextpasswordchange
Enabled
Networksecurity:LANManagerauthenticationlevel SendNTLMv2responseonly.RefuseLM&NTLM
Networksecurity:Minimumsessionsecurityfor
NTLMSSPbased(includingsecureRPC)clients
Enabled
RequireNTLMv2sessionsecurity Enabled
Require128-bitencryption Enabled

Networksecurity:Minimumsessionsecurityfor
NTLMSSPbased(includingsecureRPC)servers
Enabled
RequireNTLMv2sessionsecurity Enabled
Require128-bitencryption Enabled

UserConfiguration(Enabled)
Nosettingsdefined.


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 155 of 161




Aldo Elam Majiah

The last artifact is also the result of the risk assessment; it is a list of threat-countermeasure
pairs.


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 156 of 161




Aldo Elam Majiah



Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 157 of 161




Aldo Elam Majiah



Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 158 of 161




Aldo Elam Majiah

Appendix 8: Experts Opinion
Identification Opinion
Expert 01 She suggested that one of AD components, security of network, might potentially
have a broader scope than the AD security itself since security of network could be
interpreted as a very wide subject ranging from physical security of router/switch,
port security, etc. She suggested renaming of the component into security of
network segmentation. Additionally, she mentioned that threat caused by
virtualization could be added to AD characterization step. Virtualization threats
include inter-VM attack at the hypervisor level, multi-tenancy for AD, and lack of
hardening at VM hosts.
Expert 02 He suggested the components of AD should have strong background theory and
that AD Design & Boundary component is a critical component, which means that
if this component fails, all other components will likely fail also. It is also suggested
that the thesis also discusses ISO 31000 risk frameworks series to strengthen AD
risk framework which is derived from NIST 800-30. Additionally, expert 02 also
commented that GPO policy implementation may not be sufficient to secure a
server / workstation; administrators may need to run Security Configuration
Wizard to really secure a host.
Expert 03 He raised the concern of pass-the-hash attack on Windows platforms. He
suggested that this attack should be added to the list of threats, as it could be
used against DC and AD computer members. Pass-the-hash attack is a technique
that allows an adversary to authenticate to a remote server/service by using the
underlying NTLM and/or LanMan password hash instead of plaintext password. He
also suggested that to prevent pass-the-has attack, administrators can define high
privilege domain accounts, such as domain admins, to be able to login from
certain hosts only. Although this countermeasure does not completely thwart the
threat, it can limit pass-the-hash attack on domain accounts, thus preventing
further escalation of privilege to the domain. This feature is available using ADUC.

Another attack on Windows platform that can be added to the list of threat events
is WPAD configuration poisoning, a threat that comes from Internet Explorer
configuration flaw. Basically, an adversary could create a host, WINS entry, or DNS
entry called WPAD and redirect traffic from IE to this host. WPAD threat can
potentially enables adversary to take control of others proxy settings and retrieve
users credentials for that proxy. To prevent this threat, administrators could
create a DNS entry for WPAD tha points to corporate proxy server or they can
also disable AutoDetect proxy settings on IE clients altogether using GPO.

A comment was also added as a countermeasure for MITM attack on the network,
by implementing static ARP configuration in the switch. A static ARP entry is a
permanent entry in the ARP cache, it can be managed from a Cisco device or a
Windows hosts.

Implementation of IDS was also commented as not effective as IDS can only detect
and log the attack, but take no action on the real time attack. It is preferably to
replace IDS implementation with IPS.

Screensaver implementation on unattended workstations is also deemed a
necessary security countermeasure to prevent should surfing attack or disable the
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 159 of 161




Aldo Elam Majiah

Identification Opinion
ability of an adversary to access unattended workstations.

There was also a concern of data theft attack from Expert 03. Countermeasure of
data theft, defined as disabling the use portable media, is not considered
sufficient. Adversary can use other ways to steal and send the data outside the
organizations premises. Adversary could use email, ftp, or simply uploading the
data to their servers. In order to truly prevent data theft, an organization can use a
DLP solution. DLP solution is an integrated system designed to detect potential
data breach or data ex-filtration. DLP prevent data theft by monitoring, detecting,
and blocking sensitive data while the data are in-use in workstations, in-motion in
network traffic, and at-rest at data storage.

Last comment from Expert 03 was about environmental threat. Environmental
threats should be placed outside Security of AD computer members component
as both of these threats are different in nature, thus creating a new AD
component called Environmental threat.
Expert 04 Expert 04 suggested that environmental threats should not be included in AD
components. Environmental threat may be a threat for the organization, but it
does not really relate to AD implementation in an organization. The security GPO
resulted from the assessment may also be too restrictive for this organization. He
mentioned that the GPO may not be suitable to be implemented in all
environments, but it could be implemented in a more sensitive environment and
highest security environment such as those handling more sensitive data, those
subject to stricter compliance rules, top-secret government or military, and
organizations which handling sensitive data.
Expert 05 Expert 05 recommended to rate the countermeasures in accordance to their
threats risk level and also grouped them into people, process, and technology. As
shown in the threat-countermeasure pairs, may be proper AD documentation is a
countermeasure for a medium threat but privilege control is a countermeasure for
high risk threat. Also, he stated, a vulnerability assessment can be grouped into
process while lack of education can be grouped into people.

He also stated that there should be two separated threats related to anti-virus,
one is incorrect configuration of anti-virus, which is already in the list, and the
other is anti-virus not update. The latter threat may still exist even though the
anti-virus is correctly configured.
For threat insufficient log monitoring, the countermeasure should include
enablement of DNS logging. DNS logging is important because it can ease
investigation in detecting from which computers attacker launches an attack by
reviewing DNS requests. For example if there is a device that tries, say 500,
different DNS requests and only one or two are valid then this device is most likely
used in an attack.

Minimizing surface attack is not really a threat but a countermeasure instead. It
is a countermeasure for lack of basic security hardening implementation threat.
And for this threat there should also be a countermeasure called lack of security
hardening standards, which recommend us to have a proper documentation on
hardening OS or application.
Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 160 of 161




Aldo Elam Majiah

Identification Opinion

Mishandling of information threat needs more control such as encryption of
sensitive information.

Three of the threats related to passwords; rarely changed passwords,
inadequate password policy implementation, and inadequate account lockout
policy implementation should be combined into one threat called weak
password. A countermeasure for weak password threat includes all
countermeasures for the three original threats and one additional
countermeasure: implementation of dual custody.
Expert 06 He began with noting that there should be more information on how to
implement the countermeasures. More specific guidelines are needed for
implementing each of the countermeasures.

He noted that for patch management, two solutions are needed; one is the
monitoring (process side) and the other one is from the administrators that
monitor it (people side).

For MITM-based attack, he also added that static ARP implementation is not
enough, there should be another countermeasure implemented in the switch that
for DHCP snooping which allows only clients with specific IP/MAC addresses to
have access to the network.

In relation to sniffing threat, two countermeasures should be added. The first is to
upgrade to a more secure protocol and the second is to perform a hardening on
the switches physical access.

Next comment is about installation of unauthorized applications. From network
point of view, the organization can disable the use of unauthorized applications by
performing whitelisting in the networks firewall. As additional note, this would
require a firewall that has the capabilities of identifying applications by their
network signature.

RAT (remote administration tools) and threat caused by these tools are considered
important and deserve to be listed as a new item. These tools can use the existing
infrastructure to make connection to outside the organizations network. The
countermeasures for this threat are anti-virus implementation and application-
based firewall.


Finding Countermeasures For AD Threats Using NIST 800-30 Frameworks Page 161 of 161




Aldo Elam Majiah

CURRICULLUM VITAE

Name : Aldo Elam Majiah
Place / Date of birth : Sukabumi / November 18
th
, 1976
Mobile / Email : +6281319265243 / aldoelam@gmail.com

Description
Aldo is an IT technologist interested in IT security and infrastructure. He works as an IT
security consultant, performing various penetration testing projects mainly on Banking and
Telcos IT infrastructure and web applications. His job also consists of hardening on Active
Directory and Windows servers. Previously he worked as administrator for Active Directory,
Windows servers / workstations, and Citrix systems.
Formal education :
ST, Bachelor of Engineering Physics engineering ITB
SS, Bachelor of Art English language UNPAD

IT certifications :
ECSA: EC-Council Certified Security Analyst v4
CEH: Certified Ethical Hacker version 5.0
CISSP: Certified Information Systems Security Professional
MCITP: Enterprise Administrator on Windows Server 2008
MCSE: Microsoft Certified System Engineer: Windows Server 2003
MCSA: Microsoft Certified System Administrator: Windows Server 2003
Microsoft Certified Solutions Associate: Windows Server 2008
CCA: Citrix Certified Administrator XenApp 5.0 on 2008
MCTS: Windows Server Virtualization (Hyper-V)
MCTS: System Center Configuration Manager (SCCM) 2007
MCTS: Windows Server 2008 Active Directory
MCTS: Windows Server 2008 Applications Infrastructure
MCTS: Windows Server 2008 Network Infrastructure
MCITP: Consumer Support Technician
MCTS: Windows Vista

Working experience:
May 2012 Now, company name: ITSEC Asia, position: Principal Consultant.
Sept 2011 Apr 2012, company: PT Paserda Indonesia, position: IT Specialist Server.
Aug 2010 Sept 2011, company: PT Carrefour Indonesia, position: SysAdmin Manager
July2005 Aug 2010, company: PT Mitra Integrasi Informatika, last position: Solution
Architect / Pre-sales consultant

Вам также может понравиться