Location Research Breakthrough Possible @S-Logix pro@slogix.in

Knowledge Graph-Based Lateral Movement Path Identification in Enterprise Authentication Networks Using NetworkX and BFS, DFS Algorithms

Description

Enterprise organizations operate multiple connected systems and user accounts that communicate through authentication services. If an attacker compromises an account on one system, the attacker may attempt to use existing authentication relationships and access permissions to reach additional systems. This activity is known as lateral movement.

In this use case, an enterprise-like Linux environment is created using Ubuntu virtual machines, while Kali Linux is used as the security-testing environment. OpenSSH is used to establish controlled authentication relationships between authorized laboratory systems. A controlled lateral movement simulation is performed to determine whether the designated test account can authenticate to another system through an existing access relationship.

Nmap is used to identify active laboratory hosts and available services, while Wireshark is used to capture and inspect network traffic generated during the simulation. Authentication logs from the Ubuntu systems are collected to identify successful and failed authentication attempts and establish evidence of the simulated activity.

A publicly available labeled authentication-event dataset is also used to support authentication relationship analysis. Python and Pandas are used to process the dataset and the laboratory authentication records. NetworkX is used to construct a knowledge graph in which user accounts and systems are represented as nodes, while authentication relationships are represented as edges.

Breadth-First Search (BFS) and Depth-First Search (DFS) algorithms are applied to explore the graph and identify potential lateral movement paths from the initially compromised account. The paths identified by graph traversal are compared with the observed laboratory authentication events. Matplotlib is used to visualize the graph and its identified paths.

The complete security-validation workflow is:
Initial Lab Setup
→
Authorized Host and Service Discovery
→
Authentication Relationship Configuration
→
Controlled Lateral Movement Simulation
→
Authentication Event Collection
→
Dataset and Log Preparation
→
Authentication Relationship Extraction
→
Knowledge Graph Construction
→
BFS/DFS Graph Traversal
→
Potential Lateral Movement Path Identification
→
Observed Event Comparison
→
Path Validation
→
Graph Visualization
→
Security Findings and Final Validation

Existing Security Problem

Application/Service: Enterprise Linux Authentication Networks Using OpenSSH

OpenSSH provides secure remote access between Linux systems. Enterprise environments may contain multiple systems and user accounts connected through configured authentication relationships and access permissions.

If an attacker compromises an account that can authenticate to other systems, the attacker may attempt to use those existing relationships to move through the network. Authentication events may be recorded separately on individual systems, making it difficult to understand the complete relationship between the initial account and other systems it can potentially reach.

Existing Problem :

Host and service discovery can identify active systems and exposed services, but it does not independently establish which accounts can authenticate to which systems. Similarly, individual authentication logs may show separate login events without presenting the complete set of relationships as a graph.

Without structured authentication relationship analysis, security analysts may find it difficult to identify potential lateral movement paths, determine which systems are reachable from a compromised account, and distinguish paths predicted by a graph from movement actually observed during an attack.

The security problem is:
Initially Compromised User Account
→
Existing Authentication Relationships
→
Access to a Connected System
→
Potential Access to Additional Systems
→
Multiple Systems Become Targets
→
Difficulty Identifying Connected Access Paths
→
Potentially Risky Relationships Remain Unidentified
→
Need for Graph-Based Path Identification

The proposed solution introduces controlled SSH-based lateral movement assessment, authentication-event collection, knowledge graph construction, BFS/DFS path identification, comparison with observed laboratory events, graph visualization, and final security validation.

Attack

Specific Attack: SSH-Based Lateral Movement Through Existing Authentication Relationships

The controlled attack scenario evaluates whether a designated laboratory account, representing an initially compromised account, can authenticate to another authorized Linux system through a configured SSH authentication relationship.

Kali Linux is used as the security-testing workstation, and Ubuntu Linux provides the target systems. Nmap is used to discover authorized laboratory hosts and relevant services. Controlled SSH authentication attempts are performed using the laboratory accounts and permissions configured for the experiment.

Authentication logs are examined to determine whether the attempts succeeded or failed. Wireshark captures and inspects relevant network traffic generated during the experiment. The resulting authentication events are used to construct and validate the knowledge graph and compare potential lateral movement paths with the activity observed during the simulation.

The assessment is restricted to the isolated laboratory. Only designated test accounts and systems are used, and the simulation does not target external systems or use real compromised credentials.

Attack Behavior :
Initially Compromised Account Representation
→
Authorized Lab Host Discovery
→
Identification of an Existing SSH Relationship
→
Controlled SSH Authentication Attempt
→
Authentication Success or Failure
→
Authentication and Network Evidence Collection
→
Authentication Relationship Extraction
→
Knowledge Graph Construction
→
BFS/DFS Traversal
→
Potential Lateral Movement Paths Identified
→
Comparison with Observed Lab Events
→
Security Finding Identification
→
Final Path Validation

Security Concept

Knowledge Graph-Based Authentication Relationship and Lateral Movement Path Analysis

The primary security concept is Knowledge Graph-Based Authentication Relationship Analysis. It represents user accounts, systems, and their authentication relationships in a structured graph so that security analysts can examine how access between systems is connected.

In this project, NetworkX constructs the graph using authentication relationships extracted from the laboratory records and the publicly available labeled authentication-event dataset. User accounts and systems are represented as nodes, while the relevant authentication relationships are represented as edges. Available event attributes, such as source account, destination system, authentication result, and event source, are retained to support analysis and validation.

BFS and DFS are used to explore the graph from the node representing the initially compromised account. BFS explores connected nodes level by level, while DFS explores one branch before backtracking. These algorithms identify reachable nodes and potential paths within the graph. The resulting paths are compared with observed laboratory authentication events to determine which paths are supported by evidence and which remain predictions based on the graph.

The security process follows:

Authentication Records and Lab Events

↓

Account and System Identification

↓

Authentication Relationship Extraction

↓

Knowledge Graph Construction

↓

Initial Account Node Selection

↓

BFS and DFS Traversal

↓

Potential Lateral Movement Paths Identified

↓

Comparison with Observed Events

↓

Path Validation

↓

Graph Visualization and Analysis

Defensive Mechanism

The security concept defines the overall strategy for identifying potential lateral movement paths through authentication relationship analysis.

The following are the specific defensive mechanisms implemented.

Authentication Event Monitoring :

Relevant SSH authentication records are collected from the Ubuntu laboratory systems. Available details, including timestamps, account identities, source information, destination information, and authentication outcomes, are used to establish the sequence of observed activity.

Purpose: Provide evidence of authentication attempts and successful access during the controlled simulation.

Least-Privilege Access Control

Laboratory accounts are configured with only the permissions required for the experiment. Unnecessary SSH access and excessive account privileges are reviewed to reduce the number of systems a compromised account could potentially reach.

Purpose
  • Reduce unnecessary authentication relationships and limit potential lateral movement.

Knowledge Graph-Based Path Analysis

Authentication relationships are represented as graph edges, and BFS/DFS traversal is applied to identify possible paths from the initially compromised account to other systems.

Purpose
  • Identify potentially risky authentication paths that require security investigation.

Authentication Relationship Validation

Graph-generated paths are compared with authentication logs and controlled simulation records. Successful authentication events, failed attempts, inferred relationships, and paths that were not observed are distinguished during the analysis.

Purpose
  • Confirm whether the identified paths are supported by available authentication evidence.

Network Service Exposure Assessment

Nmap is used to identify active laboratory hosts and available services relevant to the controlled simulation.

Purpose
  • Establish the network-level visibility of the authorized laboratory systems and SSH services.

Network Traffic Inspection

Wireshark is used to capture and inspect network communications generated during the controlled authentication-based simulation.

Purpose
  • Provide supporting network evidence for correlation with authentication logs.

Post-Remediation Access Validation

After unnecessary access relationships or permissions are restricted, the controlled authentication test is repeated to verify the resulting access behavior.

Purpose
  • Confirm that the reviewed access restrictions are enforced while required authorized access remains functional.

Security Tools

Primary Graph Analysis Tool: NetworkX

NetworkX is the primary graph analysis tool because it represents authentication relationships between accounts and systems and supports graph traversal and path analysis.

Purpose
  • Construct the authentication relationship graph.
  • Represent user accounts and systems as nodes and authentication relationships as edges.
  • Apply BFS/DFS traversal to identify potential paths.
  • Retrieve reachable nodes and graph paths.
  • Support graph-based lateral movement analysis.

Authentication Data Processing Tool: Pandas

Pandas is used to process authentication-event records collected from the laboratory systems and the publicly available labeled dataset.

Purpose
  • Load and clean authentication-event records.
  • Extract relevant account, system, and event fields.
  • Prepare structured authentication relationships.
  • Preserve available authentication outcomes for validation.
  • Support comparison between observed events and predicted paths.

Graph Traversal Algorithms: BFS and DFS

Breadth-First Search and Depth-First Search are the algorithms used to explore the authentication relationship graph from the initially compromised account.

Purpose
  • Identify reachable nodes in the graph.
  • Explore potential lateral movement paths.
  • Compare the paths identified through BFS and DFS.
  • Support graph connectivity analysis.

Graph Visualization Tool: Matplotlib

Matplotlib is used to display the constructed authentication graph and highlight the paths identified during the analysis.

Purpose
  • Visualize relationships between accounts and systems.
  • Display potential lateral movement paths.
  • Present graph analysis results clearly.
  • Support the final security report.

Network Discovery Tool: Nmap

Nmap is used to discover active hosts and identify available services within the authorized laboratory network.

Purpose
  • Identify reachable laboratory hosts.
  • Discover relevant services, including SSH where available.
  • Document the initial lab network topology.
  • Support post-remediation service exposure verification.

Network Traffic Analysis Tool: Wireshark

Wireshark is used to capture and inspect network traffic generated during the controlled SSH-based simulation.

Purpose
  • Capture relevant laboratory network traffic.
  • Inspect communications associated with the controlled test.
  • Provide supporting evidence for network activity.
  • Correlate relevant observations with authentication records.

Authentication Service: OpenSSH

OpenSSH provides the SSH authentication service used to establish controlled remote-access relationships between the Ubuntu laboratory systems.

Purpose
  • Provide SSH-based access between authorized laboratory systems.
  • Generate authentication events for the experiment.
  • Support controlled authentication testing.
  • Allow verification of access restrictions.

Target Platform: Ubuntu Linux

Ubuntu Linux provides the target systems and authentication environment used for the controlled lateral movement simulation.

Purpose
  • Host the authorized laboratory systems and test accounts.
  • Provide the OpenSSH service.
  • Generate authentication records.
  • Support configuration of controlled access relationships.
  • Enable post-remediation authentication testing.

Security Testing Platform: Kali Linux

Kali Linux provides the controlled security-testing environment used to initiate authorized SSH authentication attempts and perform network discovery.

Purpose
  • Perform controlled authentication testing.
  • Execute Nmap against authorized lab systems.
  • Support collection of simulation evidence.
  • Perform post-remediation testing.

Virtualization Platform: Oracle VirtualBox

Oracle VirtualBox provides the isolated laboratory infrastructure for running the Kali and Ubuntu virtual machines.

Purpose
  • Host the laboratory operating systems.
  • Configure communication between authorized lab systems.
  • Isolate the security assessment.
  • Prevent unintended interaction with external or production systems.

Authentication Data Source: Publicly Available Labeled Authentication-Event Dataset

A publicly available labeled authentication-event dataset provides additional records for authentication relationship extraction, graph construction, and analysis. The dataset records are maintained separately from the events generated during the local laboratory simulation.

Purpose
  • Provide additional authentication records for graph analysis.
  • Support relationship extraction and path identification.
  • Enable comparison with labeled authentication activity.
  • Evaluate the analysis using records beyond the local simulation

Process

STEP 01

Prepare the Isolated Lateral Movement Testing Environment

  • Create an isolated cybersecurity laboratory using Oracle VirtualBox.
  • Configure Ubuntu Linux as the target environment and Kali Linux as the security-testing workstation.
  • Configure the virtual network so that the authorized systems can communicate with one another.
  • Record the IP addresses of the laboratory systems.
  • Verify communication between the intended systems.
  • Confirm that all testing is restricted to the authorized laboratory.
Tools: Oracle VirtualBox + Ubuntu Linux + Kali Linux
STEP 02

Configure the Laboratory Network

  • Configure the virtual network adapters for the Ubuntu and Kali Linux virtual machines.
  • Verify the assigned IP addresses and confirm connectivity between the authorized systems.
  • Record the laboratory network topology and identify the systems that will participate in the experiment.
  • Ensure that network discovery and authentication testing remain restricted to the laboratory.
Tools: Oracle VirtualBox + Ubuntu Linux + Kali Linux
STEP 03

Identify Laboratory Hosts and Services

  • Perform controlled host discovery against the authorized laboratory network.
  • Identify active laboratory hosts and discover available services, including SSH where applicable.
  • Record the discovered hosts, IP addresses, and relevant services.
  • Use the results to establish the initial network visibility baseline.
  • Do not interpret a discovered host or open port as proof of an authentication relationship.
Tools: Nmap + Kali Linux
STEP 04

Configure SSH Authentication Relationships

  • Configure OpenSSH on the Ubuntu laboratory systems.
  • Create the required test accounts and establish the authentication relationships needed for the controlled experiment.
  • Configure access permissions so that the test account can authenticate only to the intended laboratory systems.
  • Record the account-to-system relationships and verify that the authorized access configuration works as expected.
Tools: OpenSSH + Ubuntu Linux
STEP 05

Establish the Initial Authentication Baseline

  • Verify that the Ubuntu systems record relevant SSH authentication events.
  • Identify the available log fields, including timestamps, account names, source information, destination information, and authentication outcomes where available.
  • Perform authorized baseline authentication tests using the laboratory accounts.
  • Record successful and failed authentication attempts to establish the initial access state.
Tools: Ubuntu Linux + OpenSSH
STEP 06

Designate the Initially Compromised Account

  • Select a controlled test account to represent the initially compromised account in the lateral movement scenario.
  • Record the account's identity and the laboratory systems to which it has configured access.
  • Verify that the account and its authentication relationships are represented in the available laboratory records.
  • Define this account as the starting node for the later graph traversal.
Tools: Ubuntu Linux + Python
STEP 07

Perform the Controlled Lateral Movement Simulation

  • Use Kali Linux to initiate the authorized SSH authentication test against the designated Ubuntu laboratory system.
  • Perform the authentication attempt using the configured laboratory test account and its permitted access relationship.
  • Observe whether authentication succeeds or fails.
  • Where access succeeds, verify the result using the destination system's authentication records.
  • Retain the relevant evidence for subsequent graph analysis.
Tools: Kali Linux + Ubuntu Linux + OpenSSH
STEP 08

Capture and Inspect Laboratory Network Traffic

  • Capture the network traffic generated during the controlled authentication test using Wireshark.
  • Select the appropriate laboratory network interface and inspect the relevant communications between the participating systems.
  • Record the observable connection information associated with the experiment.
  • Correlate the capture with the authentication logs where possible. Do not assume that encrypted traffic exposes authentication contents or that a network connection alone proves successful access.
Tools: Wireshark + Kali Linux + Ubuntu Linux
STEP 09

Collect Authentication Records and Dataset

  • Collect the relevant authentication logs generated by the Ubuntu laboratory systems.
  • Prepare the publicly available labeled authentication-event dataset as a separate source for additional analysis.
  • Keep laboratory events and dataset records distinguishable throughout the workflow.
  • Record the source of each input so that graph results can be traced to the corresponding evidence.
Tools: Ubuntu Linux + Python + Pandas
STEP 10

Preprocess Authentication Data

  • Use Pandas to load and prepare the collected authentication records.
  • Standardize relevant fields, handle missing or inconsistent values, and identify records containing information required for relationship extraction
  • Preserve available timestamps, account identities, system identifiers, and authentication outcomes.
  • Prepare the structured records for knowledge graph construction.
Tools: Python + Pandas
STEP 11

Extract Authentication Relationships

  • Identify the accounts, systems, and authentication relationships represented in the prepared records.
  • Convert the relevant information into structured relationships suitable for graph construction.
  • Distinguish successful authentication events from failed attempts and inferred relationships.
  • Retain the source of each relationship so that the graph can be compared with the original evidence.
  • Do not invent missing relationships when the records do not support them.
Tools: Python + Pandas
STEP 12

Construct the Knowledge Graph

  • Use NetworkX to create graph nodes for the identified accounts and systems.
  • Add edges representing the authentication relationships extracted from the prepared records.
  • Retain relevant attributes, such as source account, destination system, authentication result, and event source, where the available data supports them.
  • Label account nodes and system nodes clearly so that the graph accurately represents the relationships between different entity types.
Tools: Python + NetworkX
STEP 13

Identify the Initial Graph Node

  • Select the node corresponding to the designated initially compromised account.
  • Verify that the node and its relevant authentication relationships are present in the constructed graph.
  • Use this node as the starting point for graph traversal.
  • If the account or its relationships are missing from the available records, document the limitation rather than creating unsupported connections.
Tools: Python + NetworkX
STEP 14

Apply Breadth-First Search (BFS)

  • Apply BFS from the initial account node to explore connected nodes level by level.
  • Record the reachable nodes and the potential paths identified by the traversal.
  • Use the results to examine shorter paths in the unweighted graph.
  • Treat the identified paths as potential routes represented by the graph, not as automatic proof that lateral movement succeeded during the simulation.
Tools: Python + NetworkX + BFS
STEP 15

Apply Depth-First Search (DFS)

  • Apply DFS from the same initial account node to explore connected branches of the graph.
  • Record the reachable nodes and alternative paths identified by the traversal.
  • Compare the DFS results with the BFS results to understand how the graph structure affects the paths discovered.
  • Document relevant differences between the two traversal outputs.
Tools: Python + NetworkX + DFS
STEP 16

Validate Potential Paths Against Observed Events

  • Compare the paths identified by BFS and DFS with the authentication events collected during the controlled laboratory simulation.
  • Use available account identities, destination systems, timestamps, and authentication outcomes to determine which paths are supported by observed activity.
  • Analyse the publicly available labeled authentication-event dataset separately.
  • Distinguish paths supported by successful authentication records from paths that are only predicted by the graph or cannot be validated using the available evidence.
Tools: Python + Pandas + NetworkX
STEP 17

Visualize the Graph and Review Security Evidence

  • Use Matplotlib to visualize the authentication graph and highlight the paths identified by BFS and DFS.
  • Clearly distinguish the initial account, connected systems, and relevant authentication relationships.
  • Review the graph alongside the Nmap results, authentication records, and Wireshark captures.
  • Use each tool's evidence only for the purpose it supports. Host discovery and network traffic alone must not be treated as proof of successful lateral movement.
Tools: Python + NetworkX + Matplotlib + Nmap + Wireshark
STEP 18

Perform Final Security Validation and Report the Findings

  • Review the results of the controlled SSH authentication simulation.
  • Compare the initial authentication state with the observed laboratory events and the paths identified by graph traversal.
  • Identify potentially unnecessary authentication relationships and review the relevant access restrictions.
  • Repeat the controlled authentication test after applying any required access restrictions.
  • Verify that unauthorized access is denied while required authorized access remains functional.
  • Document the graph paths, observed events, validation evidence, remaining limitations, and final security findings.
Tools: Python + Pandas + NetworkX + Matplotlib + Nmap + Wireshark + OpenSSH

Outcome

An isolated Linux laboratory is established using Oracle VirtualBox, Ubuntu Linux, and Kali Linux to assess SSH-based lateral movement through configured authentication relationships.

Authorized laboratory hosts and available services are identified using Nmap, establishing the initial network topology and identifying relevant SSH services.

A controlled lateral movement simulation is performed using designated laboratory accounts to determine whether an initially compromised account can authenticate to another system through an existing authentication relationship.

Authentication logs are collected from Ubuntu systems, and Wireshark captures provide supporting evidence of the network communications generated during the simulation.

A publicly available labeled authentication-event dataset is processed separately from the laboratory records to provide additional authentication relationships for graph analysis.

A knowledge graph is constructed using NetworkX to represent user accounts, systems, and authentication relationships identified in the available records.

BFS and DFS algorithms are applied to identify reachable nodes and potential lateral movement paths from the initially compromised account.

The paths identified through graph traversal are compared with observed authentication events to distinguish evidence-supported findings from paths predicted by the graph.

Graph visualization using Matplotlib presents authentication relationships and potential lateral movement paths, helping security analysts identify potentially risky access relationships for further investigation.

The complete lateral movement assessment, authentication-event collection, knowledge graph construction, BFS/DFS path identification, evidence-based path validation, graph visualization, and final security reporting workflow is demonstrated.