ACT NOW TO MITIGATE RISK

1. User behavior monitoring on servers helps identify anomalous activity and provide objective investigative context despite the inherent complexity and variability of privileged server access.
2. All server access, especially for external parties, should be formally requested, least‑privileged, time‑bound, and automatically expired to reduce unnecessary exposure and maintain accountability.
3. Applying foundational controls, such as restricted shells, strong credential hygiene, no password reuse, and time‑bound IP allow‑listing, significantly limits privilege escalation and lateral movement opportunities.
4. Regular penetration testing validates that security controls operate as intended and exposes misconfigurations or legacy weaknesses before they can be exploited for deeper access.

INTRODUCTION

Servers are frequent targets in security incidents as they hold sensitive data. Despite cloud shifts, they host credential databases, backups, and privileged access. In hybrid setups, they link closely with cloud infrastructure, making them key attacker targets.

Monitoring servers is tough. Each supports different functions, users, and shared accounts. Automation and AI agents with delegated credentials add complexity, creating noisy environments where malicious actions mix with legitimate ones.

This iTA covers a third-party contractor abusing access to escalate privileges, persist, access servers after hours, and move laterally. We show initial alerts, behavioral signals giving context, and visibility enabling quick, confident investigation. Though server monitoring is hard, behavioral context reveals intent early, helping defenders focus on key threats.

DTEX INVESTIGATION AND INDICATORS

This investigation proved to be one of the more challenging cases our i³ analysts have handled. It required correlating activity not only across multiple endpoints, but also across multiple user accounts, and stitching those actions together into a single, coherent timeline that accurately reflected the insider’s behavior. Under normal circumstances, this level of reconstruction is extremely difficult. However, having strong user context significantly aided the effort, allowing analysts to identify user‑initiated commands that led to privilege escalation and to clearly observe pivots from one server to another.

What ultimately accelerated the investigation was the organization’s out‑of‑hours detection capability. The organization had a well‑defined understanding of when legitimate server access and maintenance typically occurred, which enabled them to clearly define authorized change windows. This allowed activity outside those windows to be categorized under Server Access Outside of Authorized Change Window. While the investigation would have proceeded regardless, our i³ analysts were already engaging the internal team about suspicious activity earlier in the day, the out‑of‑hours detection enabled the organization to immediately trigger its incident response playbook.

The remainder of this section will walk through the categories observed during the investigation, ranging from standard user behavior profiles to more specialized server‑based categories. It will also highlight several new categories that emerged as a direct result of this investigation, which will be incorporated into future DI releases.

Stage: Reconnaissance | privilege enumeration

The initial investigation showed the insider had legitimate SSH access to a Linux server via a shared, unprivileged maintenance account and was observed enumerating its privileges.

This activity alone may reflect benign curiosity, common among IT workers when starting or returning to an account, but repeated varied attempts to determine privileges may indicate escalation attempts.

Stage: Account compromise – credential enumeration | searching shell history for password

On the shared account, the insider found a command in the Bash history file containing the plaintext password for another system account.

Apply methods to prevent password exposure, such as disabling persistent Bash history between sessions (especially for shared or common accounts), to mitigate this exploitation.

Stage: Behavior | switching user contexts

With the plaintext password, the insider switched to the postgres user account, a database administrator with privileged system access.

Database accounts often have elevated privileges that enable further privilege escalation or access to unintended server areas. The account’s intended use is segregation of duties; however, the plain text password in the previous step enabled abuse of this pathway.

Switching accounts or elevating privileges in Linux using the su or sudo commands is common but requires careful monitoring to detect potential escalation, circumvention or masquerading.

Stage: Aggregation | exporting database contents

The insider enumerated privileges from this account and discovered that the server hosted databases for multiple applications, including the building access management software under investigation and the organization’s video surveillance system.

The insider tried querying other databases but chose to export the entire database to a plain text file using the PostgreSQL export utility pg_dump.

Depending on the organization’s use cases, this may be common. However, in this investigation, exporting any content from any database was unnecessary. If exporting is uncommon, an annotation could be configured, similar to detections for dumping the Windows NTDS.dit credential database.

Stage: Exfiltration | temporary Python HTTP server

After the export, the insider tried to exfiltrate the database dump by hosting a temporary HTTP server via Python: python3 -m http.server 8080

This is a simple yet effective method for transferring files, as the Python module can be used to host files from an arbitrary directory on any port number TCP/1024 or higher without root or additional privileges. Assuming the network connection is not blocked, any remote user can then use a web browser to connect to the specified host and port number to download the files.

However, in this instance, the network firewall blocked the connectivity to the host on the insider’s chosen port (TCP/8080), and no further exfiltration attempts occurred at this point.

Detecting users attempting exfiltration methods that bypass security controls is valuable for establishing intent during incident response.

Stage: Circumvention | port forwarding or tunneling via terminal

With the network firewall blocking inbound access to the Linux server, the insider then attempted an outbound connection via SSH to several IP addresses that were later determined to be linked to a hosting service used by several APT actors.

Stage: Circumvention | software installation, reverse shell connection

The insider assumed outbound SSH was blocked and tried to establish a session using socat, a tool like netcat often used in living-off-the-land (LotL) attacks for reverse shells. Using a native tool instead of known or bespoke command-and-control packages, the activity evaded traditional AV/EDR detection.

Since neither netcat nor socat were installed and the insider had sudo access, they installed socat using the Linux package manager (dnf).

Packages are frequently updated, making this a common observation.

Stage: Circumvention/persistence | local user account creation, hidden users

After validating that the reverse shell was connected and stable, the insider then proceeded to create a hidden user account to attempt to remain under the radar. The account was not truly and “hidden” from administrators, however since no home directory was created (/home/useraccount), the account may have remained less obvious to system users without further investigation.

Stage: Circumvention/persistence | local job scheduling execution

The insiders’ hidden account maintained persistence by creating a scheduled cronjob that reconnects to the reverse session every few minutes.

Because of how the account was created in the last stage, some investigators might mistake the cronjob for a legitimate service account automation task. This obscurity can slow investigations and sometimes cause dead ends, especially during a live compromise.

Stage: Reconnaissance | searching for SSH private keys

This reconnaissance can lead to further persistence. The general recommendation after a compromise is to reset all credentials. However, this rarely happens. Some credentials are missed, enabling swift re-compromise.

If the insider is found but not identified, or if they pass off private keys, an imminent attack is plausible.

Stage: Reconnaissance | network service scanning

The insider used tools like nslookup, arp, ping and a Bash script to scan specific ports via TCP connections:

These living-off-the-land network and port scanning methods are difficult to detect individually; they become apparent only when analyzing the full sequence of actions.

Profiles and personas

This iTA summarizes an investigation into a third-party contractor who abused their position and access to escalate privileges, install persistence, and access servers outside business hours for malicious purposes.

Third-party remote support

Role	Devices	Motivation	Timing and opportunity
Remote support for on-site technician	Own laptop, access to shared maintenance account via SSH.	Establish persistence for further reconnaissance and likely data exfiltration or espionage.	The initial persistence establishment was performed during a schedule work session. Follow up actions like lateral movement and reconnaissance were performed after hours.
Application usage	Native command line tools Socat Remote Desktop Protocol (RDP) on Windows

Persona

Contractors may use their own devices to remote into environments for support since they often support multiple organizations. The level of access they are provisioned along with the inability to monitor their device usually gives them levels of access most internal employees do not have.

This persona helps organizations conceptualize and differentiate threat-hunting strategies. By separating these behavioral patterns, teams can proactively detect and respond to risks without technical emulation.

The contractor or third-party vendor

• Motivation: Varies (often financial or negligence)
• Behavioral indicators: Short-term access, limited oversight, inconsistent behavior
• Risks: Supply chain attacks, data leaks, unauthorized access.

RECOMMENDED ACTIONS FOR EARLY DETECTION AND MITIGATION

Server user behavior monitoring

Servers are inherently difficult environments in which to monitor user behavior due to their varied and often complex roles. A single server may support multiple functions, and different servers frequently have unique purposes depending on the environment. Access is commonly shared among multiple users with varying responsibilities, privilege levels, and irregular access times. Once logged in, user activity can range from highly targeted administrative tasks to exploratory or fact‑finding actions associated with troubleshooting, making it challenging to establish a consistent baseline of “normal” behavior.

During investigations, this complexity is compounded when interviews are used to determine the purpose and intent behind observed actions, particularly when elevated privileges are involved. Reconstructing intent after the fact is often subjective and can obscure clear conclusions, slowing the investigative process. While user behavior monitoring does not eliminate these challenges, it can provide valuable context by identifying anomalous patterns, narrowing the scope of questionable actions, and helping investigators formulate more precise, evidence‑based questions. This added visibility supports clearer attribution and more efficient investigations in privileged server environments.

Access request procedures

Any access to a server or system that does not normally permit external connectivity should be governed by a formal, time‑bound access request process. External parties, such as contractors or vendors, must submit requests to IT in advance that clearly state the business justification, the specific systems or credentials required, and the estimated duration of access. Once approved, access should be provisioned with least privilege and configured to automatically expire at the end of the approved time window. If work extends beyond the original estimate, a new request should be submitted and reviewed rather than informally extending access.

In this incident, the troubleshooting activity was expected to last only a single day, so access should have been granted for that period and expired automatically that afternoon. Even though the insider ultimately used a different account, the original credentials remained active and therefore represented an unnecessary risk. Leaving unused or over‑privileged accounts enabled creates an opportunity for misuse by other parties and weakens accountability. Enforcing strict expiration and re‑approval ensures access remains aligned with actual operational needs and reduces the attack surface.

Follow basic best practice

There were several incremental control improvements that could have significantly reduced the insider’s ability to escalate privileges and move laterally within the environment. One key measure would have been configuring the shared maintenance account to use a tightly restricted shell, limited solely to the specific commands required for troubleshooting, such as viewing log files with cat. By constraining the available command set and preventing interactive shell functionality, the opportunity to explore the system, execute additional tools, or leverage local misconfigurations for privilege escalation would have been greatly reduced.

Additional safeguards could have further limited risk. Clear‑text credentials should never be exposed through command history or configuration files, and strong credential hygiene must be enforced to ensure database passwords are unique and not reused for server access or other services. Password reuse significantly amplifies the impact of a single compromise. Finally, restricting access based on allow-listed external IP addresses for only the approved maintenance window would have added a strong compensating control. Time‑bound IP allow‑listing would have likely prevented the contractor from re-accessing the environment outside of authorized hours, reducing both the window of exposure and the potential for misuse.

Penetration testing your network security

This investigation underscores the disconnect that can exist between a network’s intended security design and its actual implementation in a production environment. Multiple security weaknesses were identified, including reliance on an outdated version of a restricted shell, insufficient segmentation between internal Windows servers and externally accessible systems, and gaps in application control. Individually, each of these issues increases risk; collectively, they create multiple paths for a malicious insider to gain access and move deeper into the environment than originally intended.

Regular penetration testing can help identify these types of weaknesses before they are exploited. Conducting such testing at least annually, and whenever significant network or architectural changes are introduced, allows organizations to validate that controls are operating as designed. Proactive testing can uncover misconfigurations, legacy components, and trust relationships that enable lateral movement, thereby reducing the likelihood of both an initial compromise and the ability of an attacker to escalate or persist once access is gained.

Some parts of this Threat Advisory are classified as “limited distribution” and are accessible only to approved insider risk practitioners. To view the redacted information, please log in to the customer portal or contact the contact the i³ team.

INVESTIGATION SUPPORT

For intelligence or investigations support, contact the DTEX i³ team. Extra attention should be taken when implementing behavioral indicators on large enterprise deployments.