Detecting Malicious Command-and-Control Infrastructure Targeting GitLab Servers Through Threat Intelligence IOC Correlation and Network Behavior Analysis

Enterprise organizations may deploy GitLab as a self-hosted platform for source-code management, CI/CD, project collaboration, and software development operations. Because GitLab can be a critical internal application, compromise of the server or its surrounding infrastructure can create significant security risk.

Attackers may use external Command-and-Control (C2) infrastructure to maintain communication with compromised servers. If a GitLab server communicates with infrastructure associated with malicious activity, the communication may indicate a potential compromise or unauthorized outbound activity.

Traditional network monitoring can identify connections but may not provide enough context to determine whether the destination is associated with known malicious infrastructure.

Cyber Threat Intelligence addresses this problem by collecting known malicious indicators, enriching them with external intelligence, storing them in a centralized intelligence platform, and correlating them with internal network activity.

In this use case, an enterprise-like self-hosted GitLab server is deployed on Ubuntu inside an isolated laboratory. Zeek monitors the network traffic generated by the GitLab environment.

MISP acts as the central Cyber Threat Intelligence platform for collecting, storing, enriching, and correlating Indicators of Compromise (IOCs).

Open-source threat-intelligence sources such as URLhaus and AbuseIPDB are used to obtain and enrich malicious IP and domain indicators.

A controlled C2 communication scenario is safely reproduced inside the isolated laboratory. The laboratory does not connect to real malicious infrastructure. Instead, a controlled test indicator is used to represent malicious C2 infrastructure.

Zeek records the network activity, while MISP provides the associated threat-intelligence context. The network activity is then correlated with the known IOC to identify potential C2 communication involving the GitLab environment.

OpenSearch is used to visualize and investigate the correlated network activity and associated threat intelligence.

The Workflow is: GitLab Server → Controlled C2 Communication → Zeek Network Telemetry → IOC Matching → MISP Threat Intelligence → Threat Context Enrichment → Potential C2 Detection → Investigation → Risk Assessment → Intelligence Update

GitLab is the target application in this use case. It is deployed as a self-hosted application within the controlled enterprise-like environment. It may contain source-code repositories, CI/CD configurations, project information, development credentials and configuration references, application metadata, and internal development information. Because of its importance, unexpected communication between the GitLab server and known malicious infrastructure should be investigated.

The organization may have external threat intelligence identifying malicious IP addresses and domains, but that intelligence may remain separate from internal monitoring systems. As a result, a GitLab server communicating with malicious infrastructure could appear as an ordinary network connection.

The security problem is that external threat intelligence and known malicious IOCs may not be correlated with internal GitLab network activity. Without internal correlation, outbound communication from the GitLab server toward potential C2 infrastructure may remain undetected.

The security problem is therefore:

The proposed solution introduces threat intelligence collection, IOC validation, IOC enrichment, MISP-based intelligence management, GitLab network monitoring, IOC correlation, C2 communication identification, threat-context analysis, risk-based investigation, and intelligence-driven security response.

The controlled scenario evaluates whether network communication involving the GitLab server can be correlated with a known malicious C2 indicator. The assessment does not connect the laboratory to real malicious infrastructure. Instead, a controlled test environment is used to reproduce the characteristics of communication with a known malicious IOC.

The detection focuses on identifying network activity involving the GitLab server and determining whether the destination corresponds to a known malicious IP address or domain. The assessment considers IOC source, IOC reliability, indicator type, threat reputation, indicator confidence, GitLab server activity, destination IP/domain, connection frequency, connection timestamps, associated threat context, and potential impact to the GitLab environment.

The primary security concept is Threat Intelligence–Driven Detection.

The objective is to convert external threat intelligence into actionable security information for the GitLab environment. The assessment considers IOC source, IOC reliability, indicator type, threat reputation, indicator confidence, GitLab server activity, destination IP/domain, connection frequency, connection timestamps, associated threat context, and potential impact to the GitLab environment.

The secure processing flow is: