Hello everybody,
In the previous post we saw the final steps of the proposed methodology, in this post we will give a few hints on different recommendations proposed to protect the AD service from attackers that make use of the tools and attack vectors previously seen.
Weak Passwords
The action a system administrator should take is to establish a strong password convention, with 8 characters or more, including symbols, numbers and some capital letters, that cannot be repeated over time. This will make it more costly to obtain a password in offline brute force attacks.
It is possible to improve the level of security by different measures, some of which can be applied directly to Active Directory Group Policies, such as:
Regular change of passwords for all users, i.e. a “short” expiry of about 3 months could be established, so that the user changes the password in each of these periods.
To avoid the repetition of passwords, it is possible to establish that the user cannot repeat the last 10 passwords that he/she has used as an Active Directory user.
On the other hand, it is possible to apply other measures through the use of third party tools that can be “merged” with the Active Directory operations:
The use of a password manager, this allows the user to only have to remember a single password and to set different passwords for each of the services, preventing that if one of them is obtained, the rest of the services cannot be accessed. However, this differs from the current trend of companies focusing on the implementation of Single Sign-On (SSO), which is a procedure that allows authentication to different systems through a single identification process. In addition, with the implementation of a password manager you can delegate the security of passwords to that provider.
Use of two-factor authentication, which introduces a new level of security when generating an authentication, this is done through the requirement of double identification, the first, the password known by the user and the second an alphanumeric code that is generated randomly in different periods of time, this prevents an attacker can access the system with only a password hash or the password itself.
Equipment names
A starting security error has been the name of the equipment, so there are different conventions when establishing a name for the equipment, the most advisable is that they are not descriptive in reference to the services they host, that is, do not call a server that contains an Active Directory: “AD”, “Active Directory”, “Domain Controller”… or a computer that contains the company’s web: “WebServer”, “hosting”, etc. hosting”, etc.
There is a RFC for this purpose, among which a few recommendations stand out:
- Do not use long names.
- Avoid alternative spellings, such as interchanging letters in a word, in order to make a pun.
- Avoid domain names.
- Avoid names similar to the domain name.
- Do not use antagonistic names or insults.
- Do not use digits at the beginning of the name.
- Do not use non-alphanumeric characters.
- Do not expect upper and lower case letters to be maintained in the name.
The criteria that should be followed will depend on the needs of the environment where the equipment is deployed, here is an example:
Frame:
If it is a local framework, i.e. with a single site, no concept would be needed for this section.
f it is a provincial framework, with more than one site within the same province, a concept could be established depending on the site, if the equipment is in the main site: 01, if it is another site, 02-03-04-etc…
If it is a national framework, it would be possible to establish a code for each of the provinces, for example, associated with the telephone prefixes of each of them:
- Andalusia:95X
- Aragon:974/976/978
- Asturias:984/985
- Balearic Islands:971
- …
Finally, if it is an international company, a country code could be established:
- Spain: ES
- France: FR
- Portugal: PT
- Italy: IT
- …
Employee
Usually employee management systems identify employees by numerical codes, so this could be included in the team name.
Type of equipment
- SV: If it is a server.
- V: Virtual
- F: Physical
- L: If it is a laptop.
- D: If it is a desktop computer.
Other concepts
It is possible to add more codes such as the department to which the equipment belongs or the operating system it uses, however, in order to maintain a logical length within the RFC, as seen above, it can be kept with the concepts indicated in the previous sections.
With these sections defined, we could establish the following nomenclature for the following example: the name of a laptop (L) in an international organisation in Spain (ES), located in Madrid (91), which uses the user 1234 in the main headquarters (01), could be defined as follows:
ES91011234L
As another example, a single physical server (SVV), Ubuntu (U) in an organisation that only operates locally, could be defined as follows:
SVVU01
User permissions management
A policy of total denial of access to users and groups should be maintained, allowing access to resources only by express request to the user or group. In addition, continuous maintenance of user permissions should be carried out in order to remove those that are no longer used.
Continuous and periodic evaluations
It is necessary to maintain continuous studies on the quality of the network and the connected devices. This can be done by means of a SIEM, which is software that allows the collection of information by means of logs of the network equipment and also allows to act in real time in the event of a threat.
Honeypots can also be used, which establish decoy users or equipment with services that are easily vulnerable so that an attacker can enter them and generate an alert that will be evaluated. Some of them are:
- Delilah
- ESPot
- ElasticPot
- Elastic honey
- MongoDB-HoneyProxy
- NoSQLpot
- …
Kerberos Roasting
To prevent Kerberos attack, you can use Kerberos FAST, to protect data that has been previously authenticated by securing authentication service (AS) exchanges with the KDC through a secure tunnel. The use of insecure protocols such as RC4 can also be eliminated and stronger protocols such as AES-256 can be used to protect TGTs. This prevents/complicates the exploitation of hashes obtained by an attacker.
Samba Relay y NTLMRelay
To try to avoid this type of attacks it will be necessary to execute some of the following actions (Source):
Disable LLMNR and NBT-NS: these are the protocols that allow host names to be resolved according to their IPs, achieving this without the need for a local DNS server. The problem is that they have no protection against spoofing, which can facilitate MitM attacks. (Source)
Disable NTLMv1: this version of NTLM uses a very weak protocol to perform password hashes and it is possible to obtain the password easily by brute force.
Disable IPv6: by default, all communication on Windows computers is carried out via IPv6. Disabling this protocol prevents attacks via IPv6, as it is not usually configured and hardened appropriately.
Configure SMB with digital signatures: it is necessary to sign all equipment and services, but especially SMB, since, if it is not signed, any intruder can poison the network by impersonating the requested resource and stealing the credentials of users requesting resources in the SMB protocol.
ASREPRoast
Kerberos pre-authentication must be set on all users in order to prevent leakage of hashes (Source), as attackers look for users who have the DONT_REQ_PREAUTH tag in their registry, i.e. those who are not required to pre-authenticate in kerberos.
The problem is that without pre-authentication by the Kerberos service, the attacker can send an authentication request to a service, on behalf of a user, without needing to know the user’s keys, which causes the KDC to return the TGT encrypted with that user’s password, giving the attacker the opportunity to crack it.
Golden Ticket
Once a Golden Ticket is obtained, it is very difficult to get rid of it (Source), so it is best to prevent credential theft by training users to recognise malicious links. In addition to installing terminal protection to prevent attackers from loading malware modules, you can also create an explicit administrative connection to a single terminal so that no one can access the AD administration.
Conclusion
This would be a small brushstroke of the possible defences that the person in charge of the security of the environment could establish to be able to protect himself from the attacks that have been seen during the previous posts.
In the next and last post, we will indicate the results obtained after following the methodology and a small conclusion.