Introduction Insider Threat is a type of security test in which an auditor acts as a malicious employee and attempts to attack the organization from the inside. In this way, internal threats can be detected that the company might face in the event of an employee's workstation access being compromised, as well as the potential risk when the employee themselves has malicious intentions. The client provides a workstation configured identically to other employee workstations, as well as additional credentials that allow connection to email systems, the Intranet, or VPN. In other words - an artificial employee is created whose goal is to detect vulnerabilities, exfiltrate sensitive data, or - if possible - take control of the network or key servers.

During such an audit for one of our clients, full administrative access to the Domain Controller was obtained in a very short time. Thanks to files from the .git directory accessible via the HTTP server, the auditor gained unauthenticated (requiring no additional credentials) access to the full source code of the Intranet application. As a result, access was discovered to dozens of passwords in clear text, including the administrative database password, domain administrator passwords, passwords for services used in the company ([REDACTED]), and VPN configurations of most users.

Identification of this vulnerability occurred during the initial phase of the audit and took a small amount of time. The auditor assesses the complexity level of exploiting the described vulnerabilities as easy and not requiring advanced knowledge. This factor significantly increases the criticality of the reported vulnerability. A simple configuration error allowed for the takeover of the domain controller within the first few hours. Access to the code also allowed for the identification of other vulnerabilities, submitted to the client in the report.

Taking over the domain controller gives a potential attacker a very broad scope for abuse. A domain administrator has the ability to log in to all workstations or servers joined to the AD, disabling security systems, downloading sensitive data, or executing malicious software. Thanks to the obtained privileges, the auditor was able to penetrate the sensitive part of the network, gaining access to a large amount of invoices, personal data, contracts, agreements, or access data to banking systems used by accounting. TECHNICAL DETAILS (PROOF OF CONCEPT)Phase #1 -Bassic Reconnaissance The first stage was the identification of the employee portal at the address [REDACTED]: The application returns the following response: The header reveals information that the application is running in a Windows environment, using Apache server 2.4.58 and PHP version 8.1.12. Both versions are not up to date.

An additional, important element is the observation that the application is running on the same server as the domain controller: The next step was finding the standard version control system configuration file at the address https://intranet.[REDACTED].com/[REDACTED]/.git/config: The above indicates not only the fact of storing the application source code on GitHub, but also provides a potential possibility of gaining access to the application source code. Phase #2 – Accessing the source code Access to the .git directory may in some cases allow obtaining access to the source code, specific changes and their descriptions or similar. To this end, the Dumper and Extractor tools from the GitTools package were used. First, it was necessary to download as many files as possible from the .git directory: Next, the Extractor application allowed for the reconstruction of the application's source code: Phase #3 – Domain Controller takeover The auditor undertook the analysis of the source code in search of sensitive data. In a short time, the following credentials were identified: Further analysis showed that the mentioned user is a domain administrator: With a domain administrator account, it was possible to log in to other computers on the network with administrator privileges, as well as to download the database of all users in the domain and attempt to crack their passwords. The following credentials were found in the next file: Mr. [REDACTED] is highly likely the author of the Intranet application, his name appears in several places in the code, including the credentials. While this user does not possess administrative privileges, the same password is used for the user adm_[REDACTED], who does hold administrator privileges - providing the auditor with alternative access to the domain in the event of the detection and change of the first password. Phase #4 – Review of the database In the configuration file, it was also possible to find credentials used to connect to the database: Access is facilitated by the web-accessible phpmyadmin application, which allows for database management: [REDACTED] Using the previously found credentials, it was possible to gain access to the database: A review of the data contained in the database revealed, among other things, the tbl_documentation_desc table, which contained a large number of plain text passwords for various integrations. The following SQL query was used: As a result of which, the following list was returned: Additionally, one entry with a note can be found, in which we find further passwords: Many of these access points may be potentially interesting for an attacker, however, focusing on further technical network reconnaissance or privilege escalation, access to the Any Desk panel is interesting: This allows the auditor to remotely manage connected computers: Additionally, the tbl_users table can be found in the database, containing among other things:

• VPN configurations
• AnyDesk identifier
• in some cases - the intranet login password hash (most accounts do not have a password and login is performed via OAuth)
• Credentials for the Vici system (in plain text)
Phase #5 – Further network analysis Among all the standard VPN configurations for agents, the configuration of Ms. [REDACTED] from the accounting department drew particular attention. In addition to standard IP addresses, Ms. [REDACTED] also had access to other subnets. Below is the configuration file found in the database: The auditor successfully connected to the VPN using the above configuration, gaining access to additional servers that were not available to a regular agent. Example host previously inaccessible to the auditor: One of the key servers was the one located at address 192.168.7.62, on which accounting documents were located, which were downloaded by the auditor: Examples of found files – presented below. Bank account statements: CV of employees: Documents: Additionally, the accountant's account has high administrative privileges: Additionally, the following passwords saved in the browser were found (the example below presents only URLs and usernames): FINAL NOTES Final assessment of the Intranet service indicates that if the system is to remain operational, it requires significant hardening. A critical architectural concern is the current hosting environment; the application must be migrated from the Domain Controller to a dedicated, standalone server running the latest stable software versions.

Regarding the application logic, the exposure of the .git directory and the presence of hardcoded credentials in the source code represent severe security risks. Consequently, all exposed passwords must be treated as compromised and rotated immediately. Furthermore, keeping the codebase on external third-party servers (GitHub) requires re-evaluation. Given the active usage by employees and support staff, a dedicated, comprehensive security audit is essential to address the underlying vulnerabilities beyond simple configuration changes.