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

LSTM-Based Investigation of Linux Insider Threats Through Unauthorized Sensitive-File Exfiltration Using Linux Audit Logs

Description

Linux systems are widely used to store sensitive files, manage user accounts, execute applications, and provide access to organizational resources. Security monitoring mechanisms can record user authentication, file access, process execution, permission changes, and other activities that help investigate potential insider threats.

Unauthorized sensitive-file exfiltration occurs when a user or another party with access to a system attempts to transfer sensitive information outside its authorized storage or access boundary. Such activity may involve accessing sensitive files, collecting their contents, staging files for transfer, and attempting to move information through an unauthorized channel.

Individual file-access events may appear legitimate when examined independently. However, a sequence of user activities may provide additional context about whether the overall activity requires investigation.

In this use case, a Long Short-Term Memory (LSTM) neural network is used to analyze ordered Linux user-activity sequences associated with sensitive-file access and potential exfiltration. An existing public security or user-activity dataset is used as the primary data source rather than manually creating the main dataset.

The dataset is examined to determine whether it contains suitable event sequences, relevant user-activity attributes, and reliable labels or reference information for evaluating the intended scenario. Linux audit logs collected during controlled laboratory testing may provide supplementary evidence where their event structure can be mapped consistently to the model's input representation.

The LSTM model processes sequences of user-activity events to learn temporal relationships between events. Its output is evaluated against the available reference labels or controlled test observations. The system supports investigation of suspicious activity sequences; it does not independently prove that a user intentionally exfiltrated sensitive information.

The complete workflow is:
Public Security/User-Activity Dataset
→
Dataset Inspection
→
Log Preprocessing
→
User-Activity Sequence Construction
→
LSTM Model Training
→
Model Validation
→
Linux Sensitive-File Environment
→
Controlled Exfiltration Scenario
→
Linux Audit Log Collection
→
Sequence Preparation
→
LSTM Analysis
→
Suspicious Activity Identification
→
Evidence Validation
→
Investigation Report

Existing Security Problem

Application/Service : Linux File System and Linux Audit Logging Environment

Linux file systems store information used by applications and users. Access permissions and other security controls help restrict access to sensitive resources. Linux audit and system-logging facilities can provide records of relevant activity, depending on the configuration and events being monitored.

However, individual log records do not always provide enough context to understand the complete sequence of activity associated with possible sensitive-file exfiltration.

Existing Problem :

A user may have legitimate permission to access certain files but may subsequently perform activities that require additional security review. For example, a sequence involving sensitive-file access, repeated file operations, staging activity, and an attempted transfer may warrant investigation when it deviates from the expected authorized workflow.

Simple event searches can identify particular activities, but they may not adequately represent temporal relationships between multiple events.

The security problem is:
Authorized Linux User Account
→
Access to Sensitive Files
→
Unusual Sequence of File Operations
→
Potential File Collection or Staging Activity
→
Attempted Unauthorized Data Transfer
→
Security Events Recorded Across Available Logs
→
Temporal Relationships Require Analysis
→
Potential Insider Threat Requires Investigation

The proposed solution uses an LSTM model to analyze ordered user-activity sequences. The model learns temporal patterns from suitable existing data and evaluates new sequences for activity associated with the defined investigation objective

Attack

Specific Attack : Unauthorized Sensitive-File Exfiltration

Unauthorized sensitive-file exfiltration involves attempting to transfer sensitive information beyond its authorized storage or access boundary.

In this use case, the attack scenario is reproduced in an isolated Linux laboratory using designated test files and test accounts. The scenario examines the sequence of activities associated with accessing a sensitive test file and attempting an unauthorized transfer through a controlled test channel.

The test does not involve real confidential information, real employee accounts, or unauthorized external systems.

Linux audit and system logs are collected according to the available logging configuration. The collected events are examined to determine whether the sequence can be represented consistently with the activity features used by the LSTM model.

The model's result is treated as an investigation signal. A suspicious sequence is not automatically proof of successful exfiltration or malicious intent.

Attack Behavior :
Linux User Account
→
Access to a Designated Sensitive Test File
→
Sensitive-File Read Activity
→
Additional File Operations or Staging Activity
→
Attempted Transfer Through a Controlled Test Channel
→
Linux Audit and System Events Recorded
→
Relevant User-Activity Records Collected
→
Chronological Activity Sequence Constructed
→
LSTM Sequence Analysis
→
Suspicious Activity Sequence Identified
→
Original Events and Test Outcome Verified

Security Concept

LSTM-Based Temporal User-Activity Analysis for Insider-Threat Investigation

The primary security concept is sequence-based analysis of user activity. Instead of evaluating each event only as an independent observation, the LSTM model processes ordered events to learn temporal relationships within a user-activity sequence.

The approach has three main components.

User-Activity Sequence Construction : Relevant events are organized chronologically using available timestamps and other suitable identifiers. The sequence may contain file-access operations, user-session activity, process events, or transfer-related records when those attributes are available. The objective is to represent the order of user actions without inventing missing events or assuming that every dataset contains the same fields.

LSTM-Based Sequence Learning : The LSTM model processes prepared sequences of user activity and learns temporal patterns represented in the training data. For supervised sequence classification, the dataset must provide suitable labels or defensible reference outcomes. If the available data does not support a reliable supervised classification task, the model objective must be adjusted before training.

Sequence Evaluation and Evidence Validation : The trained model evaluates held-out sequences and, where compatible, sequences collected during controlled Linux laboratory testing.

Predictions are compared with available reference labels or the known laboratory test conditions. The original records are then reviewed to determine whether the activity actually supports a suspected exfiltration scenario.

The assessment follows:
Public User-Activity Dataset
→
Event Preprocessing
→
Chronological Sequence Construction
→
LSTM Training
→
Sequence Classification
→
Held-Out Sequence Evaluation
→
Controlled Linux Activity Collection
→
Audit-Event Sequence Preparation
→
LSTM Inference
→
Suspicious Sequence Identification
→
Evidence Correlation and Validation

Defensive Mechanism

The security concept defines the overall detection and investigation strategy.

The following are the specific defensive mechanisms implemented.

User-Activity Sequence Monitoring :

Available user-activity events are organized chronologically so that related operations can be examined together.

Purpose: Available user-activity events are organized chronologically so that related operations can be examined together.

LSTM-Based Sequence Analysis

The LSTM model analyzes prepared user-activity sequences and generates predictions according to the objective supported by the training data.

Purpose
  • To identify activity sequences that match the learned suspicious-activity patterns

Sensitive-File Activity Correlation

File-access events are examined alongside relevant user-session, process, and transfer-related records where those events are available.

Purpose
  • To provide broader context for investigating potential sensitive-file exfiltration.

Consistent Event Preprocessing

Training, validation, testing, and compatible laboratory records are processed using a consistent feature representation.

Purpose
  • Training, validation, testing, and compatible laboratory records are processed using a consistent feature representation

Evidence-Based Validation

Model predictions are compared with original audit records, dataset labels, or documented laboratory outcomes.

Purpose
  • To determine whether a suspicious sequence is supported by evidence rather than relying only on a model prediction.

Investigation Record Preservation

Relevant source events, sequence identifiers, model predictions, and validation findings are preserved for review.

Purpose
  • To make the investigation traceable and support repeatable analysis.

Controlled Laboratory Testing

The sensitive-file exfiltration scenario is restricted to designated test accounts, test files, and an isolated test environment.

Purpose
  • To evaluate the workflow without exposing real sensitive information or targeting external systems

Security Tools

Primary AI/ML Model: Long Short-Term Memory (LSTM)

LSTM is a recurrent neural-network architecture designed to process sequential data and learn temporal relationships between observations.

Purpose
  • Learn patterns from ordered user-activity sequences.
  • Process relationships between events over time.
  • Generate sequence classifications when suitable labels are available.
  • Evaluate whether a new sequence resembles patterns learned during training.

AI Framework: PyTorch

PyTorch is used to implement, train, and evaluate the LSTM model.

Purpose
  • Define the LSTM architecture.
  • Prepare and process sequence tensors.
  • Train the model using the selected training data.
  • Generate predictions for held-out sequences.

Programming and Automation Tool: Python

Python provides the main environment for the data-processing, model-training, and evaluation workflow.

Purpose
  • Integrate event processing and LSTM inference.
  • Automate sequence construction.
  • Manage training and evaluation.
  • Generate investigation results.

Data Processing Tool: Pandas

Pandas is used to load, filter, organize, and analyze the existing public dataset and compatible laboratory records.

Purpose
  • Process available event records.
  • Organize event attributes and timestamps.
  • Prepare data for sequence construction.
  • Associate predictions with their source records.

Numerical Processing Tool: NumPy

NumPy supports numerical operations required for preparing the model's input data.

Purpose
  • Represent processed features numerically.
  • Support sequence-array preparation.
  • Assist with data transformations.

Model Evaluation Tool: Scikit-learn

Scikit-learn is used for supported dataset splitting and evaluation metrics.

Purpose
  • Prepare training, validation, and test partitions where appropriate.
  • Calculate precision, recall, F1-score, and confusion-matrix results for labelled classification tasks.
  • Compare model predictions with available reference labels.

Linux Security Telemetry: Linux Audit and System Logging Utilities

Linux audit and system-logging utilities provide records of configured events in the controlled environment.

Purpose
  • Collect available file-access and process-related events.
  • Record relevant user and system activity.
  • Support investigation of the controlled test scenario.

Controlled Security Testing Environment: Kali Linux

Kali Linux is used as the controlled security-testing environment where required for the laboratory scenario.

Purpose
  • Support authorized testing.
  • Initiate controlled test activity against the designated Linux environment.
  • Help validate the security-monitoring workflow.

Application and Analysis Environment: Ubuntu Linux

Ubuntu Linux hosts the designated test files, Linux logging facilities, and the analysis workflow where appropriate.

Purpose
  • Provide the Linux environment for controlled file-access testing.
  • Collect available security telemetry.
  • Support Python-based model evaluation.

Virtualization Platform: VirtualBox

VirtualBox provides the isolated virtual-machine environment used for the experiment.

Purpose
  • Host the Ubuntu and Kali Linux virtual machines.
  • Separate controlled testing from the host environment.
  • Support repeatable laboratory testing.

Process

STEP 01

Prepare the Isolated Laboratory Environment

  • Prepare the laboratory using VirtualBox.
  • Configure Ubuntu Linux as the primary file-system and analysis environment.
  • Configure Kali Linux as the controlled security-testing environment if required for the selected test scenario.
  • Establish only the network connectivity needed for the authorized laboratory.
  • Verify the virtual-machine configuration and ensure that testing is restricted to the designated environment.
  • Confirm that real confidential data and production systems will not be used.
Tools: VirtualBox + Ubuntu Linux + Kali Linux
STEP 02

Configure the Linux File-System Environment

  • Prepare a dedicated test directory on Ubuntu.
  • Create designated test files containing non-sensitive sample information.
  • Establish separate test-user permissions where required by the experiment.
  • Record the intended access permissions and expected legitimate operations.
  • Verify that the test files and accounts are isolated from real user data.
  • Document the initial file-system state before testing.
Tools: Ubuntu Linux + Linux File-System Utilities
STEP 03

Configure Linux Security Logging

  • Review the available Linux audit and system-logging facilities.
  • Determine which file-access, process, authentication, and privilege-related events can be recorded in the environment.
  • Configure suitable logging for the controlled test, subject to available permissions.
  • Generate a benign test event and verify whether the expected record appears.
  • Record the available fields and known logging limitations.
  • Do not assume that all file operations or attempted transfers will automatically be recorded.
Tools: Ubuntu Linux + Linux Audit and System Logging Utilities
STEP 04

Obtain the Existing Public User-Activity Dataset

  • Identify and obtain an existing public security or user-activity dataset suitable for sequence analysis.
  • Review its documentation, usage conditions, event structure, and available labels.
  • Determine whether the data contains ordered user activities and sufficient information to support the intended exfiltration investigation.
  • Check whether the records include relevant file-access, user-session, process, or transfer-related events.
  • If the dataset does not contain sufficient evidence for the intended scenario, choose a more suitable public source or revise the investigation scope.
  • Preserve the original dataset and its documentation.
Tools: Python + Pandas + Ubuntu Linux
STEP 05

Inspect the Dataset Structure

  • Load the dataset into Python.
  • Inspect the available fields and record formats.
  • Identify available timestamps, user identifiers, activity types, process attributes, file-related events, transfer-related information, and labels.
  • Determine which fields can be used to construct chronological user-activity sequences.
  • Check whether records can be associated with individual sessions or users without making unsupported assumptions.
  • Document any missing attributes that limit the investigation.
Tools: Python + Pandas
STEP 06

Preprocess the User-Activity Records

  • Clean malformed or unusable records where appropriate.
  • Standardize timestamp formats and event representations.
  • Handle missing values according to the meaning of each field.
  • Preserve meaningful repeated events because repeated activity may be important to sequence analysis.
  • Maintain links to the original records so that model predictions can be verified later.
  • Store the processed records separately from the original dataset.
Tools: Python + Pandas + NumPy
STEP 07

Define the Sequence Analysis Objective

  • Determine the exact prediction task supported by the available data.
  • For example, if reliable labels exist, define whether the model will classify activity sequences associated with known exfiltration-related behavior versus other activity.
  • Identify the sequence-level target label and the records used to establish it.
  • Avoid assigning malicious labels based only on an assumption that unusual activity must be an attack.
  • If reliable labels are unavailable, revise the evaluation objective rather than presenting the model as a validated supervised attack detector.
  • Record the selected objective before training.
Tools: Python + Pandas + Scikit-learn
STEP 08

Construct Chronological User-Activity Sequences

  • Order relevant events by timestamp using the dataset's available identifiers.
  • Group events into user sessions or other meaningful sequences when the source fields support that grouping.
  • Convert supported activity attributes into a consistent numerical or categorical representation.
  • Define a sequence-length strategy suitable for the selected dataset.
  • Ensure that the sequence representation retains the order of events.
  • Preserve the identifiers required to trace each sequence back to its source records.
Tools: Python + Pandas + NumPy
STEP 09

Prepare Training, Validation, and Test Data

  • Separate the prepared sequences into training, validation, and test partitions.
  • Where possible, split by user, session, or time so that highly related records do not leak across partitions.
  • Maintain the corresponding labels where available.
  • Check that each partition is suitable for the intended evaluation.
  • Record the number of sequences and the label distribution in each partition.
  • Keep the test data separate from the model-training process.
Tools: Python + Scikit-learn + Pandas
STEP 10

Build the LSTM Model

  • Implement the LSTM architecture using PyTorch.
  • Configure the input representation according to the prepared user-activity features.
  • Define the output layer according to the sequence-classification objective and the available labels.
  • Select an appropriate loss function and optimizer.
  • Verify that a small batch of prepared sequences passes through the model without dimensional or data-type errors.
  • Record the model configuration used in the experiment.
Tools: PyTorch + Python + NumPy
STEP 11

Train the LSTM Model

  • Provide the training sequences to the LSTM model.
  • Use the corresponding labels if the task is supervised.
  • Monitor the training loss and relevant validation metrics.
  • Review the training process for signs of overfitting or unstable learning.
  • Adjust the model configuration only when supported by validation results.
  • Save the trained model and the preprocessing configuration needed to reproduce its inputs.
Tools: PyTorch + Python
STEP 12

Validate the Trained Model

  • Evaluate the trained LSTM using the validation sequences.
  • Compare predictions with the available reference labels.
  • Review precision, recall, F1-score, and other appropriate metrics for the selected task.
  • Inspect incorrect predictions to identify weaknesses in the learned sequence patterns.
  • Check whether the model is simply learning dataset-specific artifacts instead of meaningful activity relationships.
  • Record the validation results before evaluating the held-out test partition.
Tools: PyTorch + Scikit-learn + Pandas
STEP 13

Prepare the Controlled Sensitive-File Exfiltration Scenario

  • Define a controlled test involving the designated sensitive test files and an authorized test account.
  • Specify the expected legitimate file-access behavior and the separate unauthorized-transfer test condition.
  • Use only non-sensitive test content.
  • Keep any transfer activity confined to the isolated laboratory or a designated local test channel.
  • Document the test conditions so that the observed result can be distinguished from assumptions made during model analysis.
Tools: Ubuntu Linux + Kali Linux + VirtualBox
STEP 14

Collect the Controlled Linux Audit Events

  • Execute the approved test activities within the isolated environment.
  • Collect the available Linux audit and system-logging records
  • Record the observed file-access events, process activity, and transfer-related events where supported by the configured telemetry.
  • Verify the observed test outcome independently of the LSTM model.
  • Preserve the source records and note any missing or unobservable activity.
  • Do not claim that exfiltration succeeded unless the test evidence establishes that result.
Tools: Ubuntu Linux + Linux Audit and System Logging Utilities + Python
STEP 15

Convert Laboratory Events into Model-Compatible Sequences

  • Inspect the collected laboratory records.
  • Determine whether their event fields can be mapped to the representation used by the public dataset.
  • Apply the compatible preprocessing and feature-conversion steps.
  • Construct chronological sequences using the same ordering and sequence rules where appropriate.
  • If the public dataset and laboratory telemetry use incompatible event representations, document the limitation and do not pass misleading or fabricated features to the model.
  • Preserve the relationship between each sequence and its original laboratory records.
Tools: Python + Pandas + NumPy
STEP 16

Perform LSTM Sequence Analysis

  • Load the trained LSTM model and its required preprocessing configuration.
  • Provide compatible laboratory sequences to the model.
  • Generate predictions for the sequences supported by the model's training objective.
  • Record the prediction and its associated sequence identifier.
  • Compare the results with the independently documented laboratory outcome.
  • Treat the prediction as a signal for further investigation rather than conclusive proof of malicious intent.
Tools: PyTorch + Python + Pandas
STEP 17

Evaluate Detection Results and Investigate Errors

  • Compare model predictions with the held-out dataset labels or controlled laboratory observations where the comparison is valid.
  • Identify correct detections, false positives, and false negatives for labelled classification tasks.
  • Review the original event sequences associated with incorrect predictions.
  • Determine whether errors arise from incomplete telemetry, unsuitable labels, sequence construction, dataset mismatch, or limitations in the learned model.
  • Document cases where laboratory activity could not be evaluated because its representation was incompatible with the training data.
  • Report only the metrics supported by the available ground truth.
Tools: Python + Pandas + Scikit-learn + PyTorch
STEP 18

Finalize the Insider-Threat Investigation Report

  • Consolidate the dataset details, sequence-preprocessing configuration, model settings, and evaluation results.
  • Document the controlled sensitive-file exfiltration scenario and the independently observed outcome.
  • Record the LSTM predictions and the associated original event evidence.
  • Summarize correct detections and errors where reference labels are available.
  • Document dataset limitations, telemetry gaps, and any mismatch between public records and laboratory events.
  • Identify improvements required for future evaluation.
  • Finalize the sequence-based user-activity investigation report.
Tools: Python + PyTorch + Pandas + Scikit-learn + Linux Audit Utilities

Outcome

An isolated Ubuntu and Kali Linux laboratory is prepared for investigating a controlled unauthorized sensitive-file exfiltration scenario.

An existing public security or user-activity dataset is obtained and assessed for its suitability for sequence-based insider-threat investigation.

The available event records are preprocessed and organized into chronological user-activity sequences without manually fabricating the primary dataset.

An LSTM model is implemented and trained to analyze the temporal relationships represented in the selected user-activity sequences.

The trained model is evaluated using held-out sequences and suitable reference labels where the selected dataset supports reliable evaluation.

A controlled sensitive-file exfiltration scenario is examined using designated test files and available Linux security telemetry.

Compatible laboratory events are converted into model input sequences and evaluated against the trained LSTM model.

Model predictions are compared with original event records and independently documented test outcomes to identify supported findings, false positives, and false negatives where measurable.

The investigation documents the limitations of the dataset, the available Linux audit events, and any incompatibility between public training data and laboratory telemetry.

The complete workflow demonstrates how LSTM-based temporal analysis can support investigation of user-activity sequences associated with potential sensitive-file exfiltration, while keeping the final security conclusion dependent on verifiable evidence rather than model output alone.