Hello everybody,
After deploying and configuring all the tools we are going to proceed to present the methodology to be followed.
Introduction
The approach to be followed in this project is a mix between the traditional pentesting methodology based on different stages through which the auditor goes through when trying to vulnerate a service, machine, etc.. and a methodology of its own, in which the active services in the computers are searched, developed and executed, with different techniques, the most common vulnerabilities in this type of environments and services. This type of approach has been chosen because the current pentesting methodology covers all the sections in a very superficial way, which means that if it is followed strictly, it is possible to get stuck in one state without being able to advance to the next; in this way, the final result provided will be a mixture between the technical report and the executive report, so that anyone can understand each of the attacks.
The methodology presented for the pentesting of a Linux environment is different from a Windows environment, since the services that run in each environment are usually different, it is normal to find more known security flaws in Linux environments since it is open source and anyone can know how it works at a low level; but in a Windows environment it is more difficult to find attack vectors that directly affect the system code, since it is a “closed” system, so vulnerabilities must be sought in the services that work at a low level with the operating system.
All the steps to be followed will be presented, as if it were a pentesting proposal for a real client environment. This implies that the environment deployed for this project has the most common vulnerabilities that can be found in a company, so this approach could be used professionally in business environments.
The following process will be followed:
Scope: as far as the pentester will go in the execution of vulnerabilities on the environment.
Reconnaissance: all computers in the network will be searched and the services running on the computers will be checked. At this point, all available network users and computers shall be searched.
Services and vulnerabilities: all available attack vectors for the services running on the computers will be searched.
Execution of attack vectors: the different attack vectors will be tested and executed on the equipment. Kerberoasting, Samba Relay, ASREPRoast, to obtain user passwords; NTMLRelay to obtain session hashes and Pass The Hash to obtain information without the need for a password.
Privilege elevation tests: after obtaining valid credentials from a user with low privileges, the user’s permissions will be escalated to a user with higher privileges. At this point, the SeBackupPrivilege privilege will be violated.
Persistence: after obtaining the permissions of the system administrator user, attack vectors will be investigated and executed so that if the user changes credentials, it will still be possible to access the system. In this section, the Golden Ticket attack will be developed.
Fingerprint deletion: all files entered on vulnerable computers will be deleted.
Outline of the process
This will be the scheme that the whole work will follow:
Scheme of work
You will start with the scope of the project, going into detail on the purpose, the type of audit and the legal commitments; once the scope is established you will move on to the survey, starting with the equipment survey, then, if you get the information, you will move on to the survey of the services running on that equipment and finally to the users of the equipment; Next, all open services will be evaluated and attacks will start to be executed; when valid credentials are obtained, privilege elevation will be attempted, gaining privileged access to the AD; next, persistence will be established on the computers and finally, fingerprint erasure will be performed.
The proposed figure has been divided by colour, where green are the processes through which the pentesting is going through and the orange ones are the subset of activities within each process that allows moving on to the next one. Finally, the sections that are not marked with colours mean that they are not going to be dealt with intensively.
In order not to make this series of posts too long, let’s start by introducing the Scope phase:
Scope
Scope
For this first point, in this project, we do not include the real requests that a client may ask for, as we are not working under a real environment, but the scope proposed by this is usually the usual one in business environments, which means that a pentester can use it to present the reports and detail the work done.
The following points detail the scope that the development of this project will receive.
Purpose
Different types of tests and attacks are provided to find the bugs according to the requirements requested by the customer.
This project focuses on the vulnerabilities of an AD and the objects it collects in its network for the deployed platform, the main target will be this service, although enumerations will be executed on the clients to understand how the network works, the elevation of privileges will be performed on the AD, but the search for valid credentials will be executed on all the available computers on the network.
It should be remembered that the deployed platform is designed not to be breached by keeping its configuration as up to date as possible, so there is a probability that there are no known vulnerable elements and that the configuration of these must be modified in order to test the attacks, as we have indicated in the previous post.
Type of audit
- Black box: the pentester does not know any client data and acts outside your network.
- Grey box: the pentester acts as a client or user of the company being audited.
- White box: the pentester acts as an internal user with access to all the client’s systems.
The most complicated and difficult audit to execute in this environment would be a black box audit, where the network structure of the environment would have to be searched from the Internet in order to connect to the vulnerable network; in order not to extend this project, a mixed grey box/white box audit is proposed.
The grey box audit is usually the most common in enterprise environments, as the pentester will act as a user within the network, but will not know the client’s systems, so it will have to perform a discovery of the “client” network and establish an attack for the computers found.
The white box audit is not fully contemplated, as outside the “basic” AD services, no other vulnerable services are running that could be attacked with the administrator credentials, but once obtained, vulnerabilities will be sought to obtain persistence on the machines, so these vulnerabilities could be sought directly with this type of audit.
Legal Commitments
The pentester must sign an agreement with the client stating that he/she will not provide any information found and agreeing to access only the systems indicated by the client, as the auditor’s actions could compromise the functioning of the systems and access to personal content.
As it does not affect a client’s actual architecture, no legal commitment should be made.
But anyway, here you have a link to a document from https://elhacker.net where it illustrates all the features to be taken into account for legal commitments before performing the audit.
Conclusion
This would be all, in the next post we will see the next step of our methodology the Recognition.