Jibril is a cutting-edge runtime monitoring and threat detection engine, designed to deliver real-time insights with minimal impact on system performance. Powered by eBPF, it remains efficient even under heavy event loads exceeding hundreds of thousands of events per second–delivering real-time protection for modern environments from dev to prod.

Use Cases

Capabilities

Jibril provides comprehensive tracking across all system resources, including users, processes, files, and network connections. Its query-driven architecture ensures complete visibility and actionable intelligence into system behavior.

Key Benefits

• High Performance: Maintains efficiency with extensive event loads.

• Full Visibility: Tracks all system resources comprehensively.

• Security: Ensures robust security and tamper-evident data integrity.

• Seamless Integration: Easily integrates with existing infrastructure.

Jibril's mission is to deliver clarity and actionable insights, ensuring the security and integrity of your systems during runtime.

Jibril: A New Era in Runtime Security

Why Jibril Stands Out ?

Jibril addresses key challenges by using eBPF in a "query-driven" approach, rather than an event-streaming model. This allows Jibril to gather behavioral data from the kernel with low system overhead.

Modern IT environments generate an immense amount of events and logs. Security teams often depend on tools that stream kernel events to user space in nearly real-time. However, during traffic surges or complex kernel operations, these tools may become overloaded, resulting in system slowdowns and incomplete data collection.

1. Core Innovations in Jibril's Architecture

1.1 Event-Less, Query-Driven Monitoring

• Jibril's Innovation:

  Jibril utilizes in-kernel eBPF maps for event storage, retrieving them on-demand. This method avoids ring-buffer overload, minimizes data loss, and ensures high performance under pressure.

• Traditional Tools:

  Depend on event flooding via ring buffers to transfer kernel events to user space, often leading to bottlenecks under

1.2 Minimal Overhead, Maximum Visibility

• Ensured Data Integrity: Maps are hashed to prevent unauthorized generation or modification of keys. If a user tries to alter map data, the system becomes "tainted," allowing for detectable changes and maintaining forensic integrity.

• Kernel-Resident Data Management: By using inter-connected hashed key-value maps with strategic caching to prevent query exhaustion, Jibril minimizes frequent context switching and reduces overhead, unlike traditional streaming tools that often struggle under heavy loads.

1.3 High-Frequency Event Efficiency

• Resiliency: With Jibril's in-kernel storage, you can achieve reliable real-time monitoring without straining your CPU. In typical mid-sized enterprise environments that generate over 50,000 events per second, standard eBPF tools like side-car might struggle and drop events under heavy load. Jibril, however, remains resilient.

2. Jibril Security Model: The Technical Deep Dive

2.1 Architectural Pillars

1. Behavioral Data Integrity

   • Detection Recipe Confidentiality: The logic behind Jibril's monitoring is kept secret, preventing attackers from understanding detection patterns and reducing their chances of evasion.

   • Rate-Limiting: Jibril can impose limits on repetitive events globally, per binary, or per process, ensuring your system isn't overwhelmed by

2. Kernel/Userland Separation

   • Secure Memory Access in eBPF Programs:

     eBPF programs need to be validated by the Linux kernel's verifier, ensuring they don't access memory without authorization

   • Low-Latency Interactions: Queries happen only when needed. No constant "firehose" of events from kernel space to user space.

3. Access Control and Monitoring

   • Root-Only, Capability-Based: Only authorized root users with CAP_BPF (or CAP_SYS_ADMIN in older kernels) can load or inspect Jibril's kernel programs. Unauthorized attempts are flagged as tampering.

   • Userland Privilege Management: Jibril's daemon starts with higher privileges for eBPF initialization, then drops unnecessary capabilities. This "least-privilege" design prevents misuse of elevated permissions.

4. System Resilience

   • Tamper Detection: Any unverified writes to eBPF maps or rogue eBPF loads are caught and flagged.

   • Plugin Isolation: Each plugin or detection mechanism runs in its own thread. One faulty plugin can't bring down the entire system.

5. Compliance Alignment

   • GDPR-Focused: Jibril tracks metadata (filenames, process IDs, timestamps), not file contents. This reduces the legal overhead of processing personal data. Future enhancements will offer anonymization for deployments needing deeper compliance.

   • ISO 27001 Ready: Strong logging, access controls, and tamper alerts support the security frameworks typical of ISO 27001.

3. End-to-End Flow: From Kernel to Userland

1. Data Collection (Kernel Space)

   • Uniform Binary Object: Jibril's eBPF code can run consistently across different kernel versions—no custom modules needed.

   • Key-Value Map Storage: Events or process behaviors are hashed into eBPF maps, ensuring minimal CPU usage and quick lookups.

2. Userland Daemon

   • Detection & Pattern Matching: The daemon retrieves only relevant kernel data, analyzing it against "detection recipes" to identify anomalies or suspicious activity.

   • Plugins: Jibril's detection logic is packaged into built-in plugins organized by detection type (file operations, network flows, etc.). Each plugin runs in an isolated thread, preventing system-wide failures if a single plugin encounters issues.

3. Printers & Dashboards

   • Flexible Output: Detection events can be dispatched to stdout, logs, the listen.dev dashboard, or even summarized through an OpenAI plugin.

   • Secure Submissions: Data is sent over authenticated channels (e.g., HTTPS with API tokens), maintaining confidentiality and integrity.

5. Extensibility & Future-Ready

1. Plugins & Extensions

   • Security-by-Design: Plugins are compiled into Jibril and operate with well-defined detection recipes. Future versions aim to allow runtime extension using a descriptive language—without compromising stability.

   • Thread-Based Isolation: Each plugin is self-contained, so a faulty network-monitoring plugin won't affect file-based detection capabilities.

2. Printers

   • Built-In Dispatch: Shipping with a range of "printers," Jibril can forward detection events to logs, dashboards, or external APIs, all configured via simple toggles.

   • Optional Integrations: For advanced threat analytics, Jibril can send summarized data to OpenAI services. This leverages machine learning to interpret event patterns more intuitively—without exposing raw data.

3. Roadmap Highlights

   • Encryption & Anonymization: Future updates plan to anonymize sensitive data and optionally encrypt kernel-collected data.

   • Deeper Compliance: Enhanced support for GDPR and ISO 27001 audits with finer access logs, documentation, and optional redaction features.

6. Why Jibril is the Future of Runtime Security

1. Minimal Overhead, Maximum Insights Jibril's kernel-first approach cuts down on CPU churn, letting you monitor production traffic without debilitating slowdowns.

2. Robust Security Model Tamper detection, hashed key-value maps, and strict privilege requirements guarantee strong defenses against both external and insider threats.

3. Uncompromised Data Fidelity Even at 50,000+ events per second, Jibril captures everything. By querying on-demand, you'll never lose critical intel to ring-buffer overflow.

4. Scalable & Compliant Built with privacy and compliance in mind, Jibril easily slots into existing frameworks and enterprise security mandates.

Conclusion: Embrace the Next Generation

Jibril redefines runtime security by collecting, storing, and analyzing kernel events in a radically efficient, low-latency, and tamper-resistant way. While other solutions struggle when event volumes spike, Jibril thrives—delivering confidence, clarity, and true operational security.

The Future

If you're ready for a secure, future-proof, and highly performant approach to runtime security, Jibril is the solution you've been waiting for.

Introduction

Jibril mission: to deliver real-time insights with minimal overhead while maintaining robust security and reliability.

Comprehensive Resource Tracking

Jibril monitors a wide range of system resources to ensure no critical detail is missed:

• Users and Groups

• Machines, Hostnames, and Namespaces

• Disks, Filesystems, Volumes, and Files

• Containers, Processes, and Threads

• Protocols, Domains, Ports, and Sockets

• Network Flows

This exhaustive tracking provides the foundation for deep, actionable insights into system activity and behavior.

Powerful Resource Management

Jibril captures every interaction with system resources, ensuring a complete audit trail for security and operational monitoring. Tracked actions include:

• Creation and Destruction

• Modification through Truncate, Link, Rename, Open, and Close

• Data Access via Read, Write, Seek, and Execute

• Memory Mapping (Map) and Synchronization (Sync)

• Locking (Lock)

These detailed logs empower teams to analyze and respond to changes across their infrastructure with confidence.

Key Features and Innovations

Jibril is purpose-built to address the most critical needs of modern runtime monitoring and security. Its core innovations include:

1. Data Immutability: Ensures data integrity by preventing any alteration after capture, providing a trusted source for forensic analysis.

2. Non-Reliance on Circular Buffers: Avoids traditional circular buffers, eliminating bottlenecks and reducing complexity in data handling.

3. Real-Time Event Delivery: Ensures immediate access to events for timely detection and response to threats.

4. Integrated Kernel Status: Acts as an all-in-one introspection and tracing tool with full in-kernel state awareness.

5. Kernel Query Language (KQL): Allows precise data retrieval through direct queries to in-kernel data, enabling advanced analysis.

6. Query Caching: Enhances performance by caching frequently queried data, leveraging data immutability for faster results.

7. Rule-Based Detection: Dynamically matches rules in-kernel for proactive threat detection and rapid response.

8. Third-Party Integration: Supports plugins for external data stores (e.g., SQLite) to enable seamless data management and integration with other systems.

These features work together to deliver cutting-edge performance while simplifying complex monitoring tasks.

Efficient Information Acquisition

Jibril excels in collecting and processing critical system data through three streamlined methods:

1. Queries: Perform inventory checks and fingerprinting by querying in-kernel stores, enabling rapid insight into system state.

2. Micro Events: Capture highly efficient, minimalistic events containing only timestamps, flags, and keys, reducing overhead.

3. Detections: Use interval-based queries to in-kernel data for proactive and continuous threat detection.

These mechanisms ensure Jibril operates with precision and speed, even under demanding workloads.

Why Choose Jibril?

1. Unmatched Visibility Jibril tracks every system resource and interaction, offering a level of detail no traditional tool can match.

2. High Performance By avoiding circular buffers and leveraging immutability, Jibril achieves superior speed and reliability, even in high-throughput environments.

3. Proactive Security Rule-based detection and real-time event delivery empower teams to respond to threats before they escalate.

4. Integration Ready Flexible plugin support ensures Jibril fits seamlessly into your existing infrastructure.

Conclusion

Jibril transforms how systems are monitored and secured by combining comprehensive tracking, advanced querying, and innovative detection capabilities into a single, cohesive framework. With its focus on real-time insights, high performance, and proactive security, Jibril sets a new benchmark for modern runtime monitoring and threat detection.

Jibril: Elevate your system visibility. Enhance your security. Empower your operations.

1. Introduction

Jibril is a next-generation runtime security tool designed to monitor and detect anomalies in system behavior with precision, efficiency, and minimal system overhead. By leveraging the power of eBPF (extended Berkeley Packet Filter), Jibril collects and stores behavioral data directly within the kernel using key-value maps. This innovative approach enables advanced detections through a secure, query-driven model, ensuring high performance and reliability even in high-throughput environments. Unlike traditional security tools that rely on event-streaming mechanisms, Jibril's architecture avoids potential bottlenecks and latency issues, providing a robust solution for modern runtime security challenges.

This document outlines Jibril's comprehensive security model, detailing its architecture, data handling mechanisms, plugin and extension designs, and compliance measures. It provides an in-depth explanation of how Jibril safeguards data integrity, enforces trust boundaries, and aligns with privacy and security best practices. The document also highlights Jibril's extensibility, resilience, and future enhancement roadmap, offering readers a thorough understanding of the principles, mechanisms, and safeguards that make Jibril a robust and adaptable solution for runtime security.

2. Security Principles

Jibril's security model is built upon core principles that emphasize safeguarding data integrity, ensuring operational transparency, and enhancing resilience against potential tampering or attacks. These principles guide the design and implementation of Jibril's features and are crucial for maintaining a secure and trustworthy system.

2.1 Behavioral Data Integrity

• Detection Recipe Privacy: Jibril ensures that detection recipes, which define the patterns and behaviors to be monitored, are private and accessible only to authorized users. This privacy is critical because if malicious actors were aware of the specific detection patterns, they could potentially craft methods to bypass the detection mechanisms. By keeping these recipes confidential, Jibril maintains the effectiveness of its monitoring capabilities.

• Rate-Limiting on Repetitive Events: To prevent the system from being overwhelmed by repetitive events, Jibril implements rate-limiting mechanisms within its detection recipes. These limits can be applied per process, per binary, or globally, controlling the number of events generated within a specific time frame. This approach reduces unnecessary overhead and helps maintain system performance without compromising the effectiveness of monitoring.

• Key-Value Data-Store Architecture: Jibril stores behavioral data in eBPF maps within the kernel. These maps use hashed keys that function similarly to foreign keys in a relational database, enabling robust data linkage across different maps (e.g., linking tasks to commands or binaries to files). Root users can inspect the map formats and use these keys to link data, but they cannot generate or modify the keys themselves, ensuring the integrity and consistency of the collected data.

• Mutable Data with Traceability: Privileged users can read and change eBPF map values, but such modifications would not go unnoticed, thereby tainting the environment. The key is hashed, and any attempt to create a new hash would likely break the relationship between the data and its metadata, ensuring the integrity of the collected data.

2.2 Kernel/Userland Separation

• Detection Layers: Jibril's architecture separates detection responsibilities between kernel space and userland. The kernel-space operations focus on securely storing behavioral data with minimal interaction required between the kernel and userland. Primary detections, such as pattern matching and data analysis, are conducted in userland using the cached data retrieved from the kernel. This separation enhances security and reduces the risk of kernel-level vulnerabilities.

• Event-Free Design: Unlike traditional runtime security tools that rely on streaming events from the kernel to userland, Jibril employs a query-driven model. This design choice eliminates the risk of overload attacks that can delay detection and ensures a timely response to incidents without introducing additional latency. By avoiding event-streaming mechanisms, Jibril reduces overhead and improves performance in high-throughput environments.

2.3 Access Control and Monitoring

• Kernel Access: Access to eBPF maps and programs is restricted to root users with specific capabilities. While these users can inspect the map formats and query the stored data, they cannot directly generate the hashed keys or modify the data within the maps. Unauthorized actions, such as writing to eBPF maps, loading unverified eBPF programs, or installing kernel modules, are detected and flagged as environmental tampering events. This strict access control prevents unauthorized modifications and maintains the integrity of the monitoring system.

• Userland Privilege Management: The userland component of Jibril currently runs with root privileges and the CAP_BPF capability (supported in kernel versions 5.8 and later, or CAP_SYS_ADMIN capability in earlier kernels) to query eBPF maps and perform initialization tasks. In future releases, Jibril will drop unnecessary capabilities after initialization, adhering to the principle of least privilege. This approach reduces the risk of misuse or privilege escalation, enhancing the overall security of the system.

2.4 System Resilience

• Environmental Tamper Detection: Jibril actively monitors for actions that could compromise its integrity. These actions include unauthorized writes to eBPF maps, loading or unloading of rogue eBPF programs, and the installation or removal of kernel modules. When such events are detected, they are logged and flagged as environmental taints, alerting administrators to potential tampering or malicious activities.

• Fault Isolation: The tool's modular architecture ensures that faults or issues within plugins or extensions do not compromise the core system. Each plugin operates in isolation, typically within its own thread, so if one plugin encounters a problem, such as a crash or infinite loop, other plugins and the core system continue to function unaffected. This design enhances the resilience and stability of Jibril, ensuring continuous monitoring even in the presence of component failures.

2.5 Alignment with Compliance Standards

Jibril is designed with flexibility to align with privacy and security standards such as the General Data Protection Regulation (GDPR) and ISO 27001. While the specifics of compliance depend on deployment requirements, Jibril incorporates features and practices that support adherence to these standards.

• GDPR Compliance: Jibril collects metadata about file access, including filenames, types of access, processes accessing the files, and timestamps. It does not currently monitor file contents, which reduces concerns related to personal data processing under GDPR. However, if future enhancements introduce monitoring of file contents, Jibril will implement anonymization or obtain explicit justification for processing sensitive data to ensure GDPR compliance.

• ISO 27001 Alignment: Although Jibril is not currently deployed in environments requiring formal ISO 27001 certification, its robust logging, access control mechanisms, and tamper-detection features provide a strong foundation for aligning with the standard's requirements. Future considerations may include formal documentation of security risks, processes, and monitoring practices to support certification efforts.

3. System Architecture and Trust Boundaries

Jibril's architecture is designed to maintain clear separation between components, enforce trust boundaries, and ensure secure data handling throughout the system. The architecture consists of two main components: the eBPF loader operating in kernel space and the userland daemon operating in user space. This section details the responsibilities and security mechanisms of each component, as well as the trust boundaries between them.

3.1 eBPF Loader (Kernel Space)

Responsibilities:

• Deployment of eBPF Programs: The eBPF loader deploys eBPF programs that monitor system behavior, track relevant events, and collect data securely within the kernel.

• In-Kernel Data Storage: It provides in-kernel data storage using eBPF maps, which act as key-value stores accessible by both kernel and authorized userland processes.

Security Mechanisms:

eBPF Safety Characteristics:

• Kernel Verifier Enforcement: eBPF programs are verified by the Linux kernel's eBPF verifier before they are loaded. This verification ensures that the programs cannot perform unsafe operations, access unauthorized memory, or corrupt the kernel, providing a layer of safety not present with traditional kernel modules.

• Safety over Kernel Modules: Unlike kernel modules, which can introduce kernel-level vulnerabilities and destabilize the system, eBPF programs run in a restricted environment with enforced safety checks, making them a secure alternative for kernel-space operations.

• Userland Map Access Control:

  • Restricted Access: Access to eBPF maps is restricted to root users with specific capabilities, such as CAP_BPF. Unauthorized users or processes cannot interact with these maps, preventing unauthorized access or tampering.

  • Mutable Data with Traceability: While privileged users can query and modify the eBPF maps to retrieve and change data, such modifications would not go unnoticed, thereby tainting the environment. The key is hashed, and any attempt to create a new hash would likely break the relationship between the data and its metadata, ensuring the integrity of the collected data.

• Memory Safety:

  • Bounds Checking: eBPF programs adhere to strict bounds checking and constraints enforced by the verifier. This prevents unsafe memory operations, such as buffer overflows or invalid memory access, within the kernel.

• Tamper Detection:

  • Monitoring Unauthorized Actions: Jibril detects and logs unauthorized actions, such as attempts to write to eBPF maps, load unverified eBPF programs, or install kernel modules. These events are flagged as environmental tampering and can trigger alerts or additional security responses.

3.2 Uniform Binary Object Across Kernel Versions

eBPF programs run the same binary object across different kernel versions, ensuring consistency and compatibility regardless of the kernel version they are running on.

Benefits:

• Simplified Deployment: There is no need to maintain different versions or builds of eBPF programs for different kernel versions, simplifying the deployment process.

• Consistency: Running the same binary object ensures consistent behavior and performance across various environments.

• Reduced Maintenance: With a single binary object, maintenance efforts are reduced as there is no need to test and validate multiple versions.

• Enhanced Compatibility: Ensures compatibility with a wide range of kernel versions, reducing the risk of version-specific issues or bugs.

3.3 Userland Daemon (User Space)

Responsibilities:

• Data Analysis and Detection:

  • Pattern Matching: The userland daemon performs pattern matching and data analysis on the behavioral data retrieved from the eBPF maps. This allows for the detection of anomalies or suspicious activities based on predefined detection recipes.

  • Cached Data Utilization: It utilizes cached data to enhance performance and reduce the need for frequent kernel-userland interactions.

• Plugin and Printer Management:

  • Plugin Execution: The daemon manages plugins, which extend the detection capabilities of Jibril. Plugins run in separate threads, each with their own dispatching logic, allowing for modular and efficient execution.

  • Event Dispatching: It handles the dispatching of detection events to configured endpoints through printers, which can include standard output, files, dashboards, or other systems.

Security Mechanisms:

• Access Control and Privilege Management:

  • Limited Capabilities: The daemon runs with the minimum required privileges. After initialization tasks that require higher privileges (such as querying eBPF maps), unnecessary capabilities are dropped in adherence to the principle of least privilege.

  • Configuration-Based Restrictions: Access to sensitive APIs and plugins is restricted based on configurations and user permissions, preventing unauthorized use or modification.

• Thread-Based Isolation:

  • Plugin Isolation: Each plugin operates in its own thread or set of threads, providing execution isolation. If a plugin encounters an issue, such as a crash or infinite loop, it does not affect other plugins or the core daemon, enhancing the resilience of the system.

• Endpoint Authentication and Secure Communication:

  • Authenticated Endpoints: Printers dispatch data only to pre-configured, authorized endpoints. For example, the listen.dev dashboard accepts data submitted with specific API keys, ensuring that only authorized data submissions are processed.

  • Data Sanitization: Before data is submitted to endpoints, it undergoes strict validation and sanitization to prevent injection attacks or the transmission of malformed data.

3.4 Trust Boundaries

• Kernel/User Space Separation:

  • Data Integrity Across Boundaries: The kernel-space component (eBPF loader and maps) and the user-space daemon maintain a clear separation of responsibilities and data handling. The kernel securely collects and stores data, while the user-space daemon performs analysis without modifying collected data kernel state.

  • Secure Data Retrieval: The user-space daemon retrieves data from the eBPF maps using secure, authorized methods. Direct manipulation of kernel data structures from user space - from other processes - is not permitted, preserving data stability and security.

• Plugin and Printer Isolation:

  • Scoped Permissions: Plugins and printers operate within defined scopes and permissions, ensuring they cannot perform unauthorized actions or access restricted data.

  • Inter-Component Communication: Communication between plugins, printers, and the core daemon is controlled and monitored, preventing unauthorized data flows or interference.

4. Data Handling, Security, and Threat Mitigation

Jibril's data handling approach is designed to address the challenges of high-throughput, real-time security monitoring while ensuring data security and integrity. By employing a query-driven model and storing data within the kernel, Jibril avoids common pitfalls associated with traditional event-streaming mechanisms.

4.1 Data Storage (Kernel Space)

• In-Kernel Hashmaps:

  • Key-Value Stores: Jibril uses eBPF hashmaps as key-value stores to collect and store behavioral data securely within the kernel. These maps efficiently manage data such as events, metrics, and state information.

  • Hashed Keys: Keys used in the hashmaps are hashed, serving as a security measure to prevent unauthorized key generation or prediction. This hashing also enhances data retrieval efficiency.

• Data Characteristics:

  • No Encryption, But Hashed: Data within the eBPF maps is not encrypted, but sensitive identifiers are hashed to obscure raw values. This approach balances performance considerations with security needs.

  • Immutability and Overwriting: Once data is stored in the eBPF maps, it is immutable from the perspective of user space. New data can overwrite old entries as updates occur, ensuring that the maps contain current information without growing indefinitely.

• Garbage Collection and Resource Management:

  • Automatic Overwriting: eBPF maps have finite sizes. When they reach capacity, old or less relevant data is automatically overwritten by new entries, preventing resource exhaustion.

  • Tamper Detection: Any unauthorized attempts to modify the eBPF maps are detectable through Jibril's tamper-detection mechanisms, ensuring data integrity.

4.2 Data Movement

• Query-Driven Model:

  • On-Demand Data Retrieval: Instead of pushing data from the kernel to userland through event streams, Jibril allows the user-space daemon to retrieve data from eBPF maps on demand. This approach reduces the overhead associated with constant event streaming and minimizes the risk of data loss.

  • Elimination of Bottlenecks: By avoiding producer-consumer mismatches inherent in event-driven pipelines, Jibril ensures that high event rates in the kernel do not overwhelm the user-space daemon, enhancing system stability and performance.

• High-Performance Design:

  • Reduced Data Copying: The query model reduces unnecessary data copying between kernel and user space, as only relevant data is retrieved when needed.

  • Efficient Data Access: Tailored queries allow for efficient access to specific data sets, reducing the volume of data transferred and processed.

4.3 Data Querying

• Flexible Query Model:

  • Detection Logic-Driven Queries: The user-space daemon employs a flexible query model driven by detection logic and user-defined patterns. This allows for precise and efficient data retrieval from the eBPF maps.

• Filtering and Enrichment:

  • In-Kernel Filtering: Basic filtering can occur during query execution to minimize unnecessary data retrieval.

  • User-Space Enrichment: Data enrichment and comprehensive analysis are performed in user space, leveraging more abundant resources and avoiding the constraints of kernel-space operations.

• Access Control:

  • Authorized Queries: Only authorized processes with the necessary privileges can perform queries on the eBPF maps, ensuring that data access is controlled and monitored.

5. Extensions & Plugins Security

Plugins and extensions are essential for extending Jibril's detection capabilities and integrating with various systems. Their design prioritizes security, stability, and maintainability.

5.1 Plugins

• Built-In Design:

  • Compile-Time Extension: Plugins are built into Jibril at compile time by incorporating detection recipes into the codebase. This approach ensures stability by avoiding the risks associated with runtime extensibility, such as compatibility issues or unforeseen errors.

  • Future Extensibility: While runtime extensibility is planned for future releases—potentially through descriptive languages for defining detection logic—the current model emphasizes reliability and control.

• Grouped by Detection Mechanisms:

  • Organization: Plugins are organized based on specific detection mechanisms, such as file access events, execution patterns, or network flows. This organization promotes code reuse and consistency across plugins.

  • Shared Logic: Common logic is shared among plugins within the same group, reducing redundancy and potential errors.

• Thread-Based Isolation:

  • Separate Execution Threads: Each plugin operates in its own thread or set of threads. This isolation ensures that if one plugin experiences an issue, it does not impact the operation of others or the core system.

  • Resilience: This design enhances system resilience, as faults are contained within individual plugins.

• Maintainability and Resilience:

  • Modular Codebase: The modular architecture simplifies maintenance and allows for easier updates or additions of detection capabilities.

  • Fault Tolerance: The system's resilience to plugin failures ensures continuous monitoring and detection capabilities.

5.2 Printers

• Built-In Mechanism:

  • Predefined Dispatch Methods: Printers are built-in components responsible for dispatching detection events to various endpoints. They are not extendable at runtime, ensuring predictable behavior and reducing the risk of runtime errors.

  • Configuration-Based Enabling: Printers can be enabled or disabled through configuration files, providing flexibility in how events are dispatched without altering the codebase.

• Customizability for Specific Needs:

  • Tailored Printers: For specific customer requirements, additional printers can be developed to dispatch events to custom endpoints. This allows Jibril to integrate with specialized infrastructure or systems.

• Endpoint Security:

  • Authorized Endpoints: Printers enforce restrictions to ensure that events are only dispatched to predefined, authorized endpoints.

  • Data Validation and Sanitization: Data transmitted by printers is subjected to strict format validation and sanitization processes. This prevents injection attacks and ensures that only well-formed, secure data is sent to endpoints.

  • Authenticated Channels: Communication with endpoints utilizes authenticated channels, such as APIs secured with tokens or keys, to protect data integrity and confidentiality.

6. Compliance Measures

Jibril incorporates measures to ensure compliance with data protection regulations and industry standards, focusing on data privacy, security of submitted data, auditing, and regulatory alignment.

6.1 Data Privacy

• Strict Data Collection Policies:

  • Minimal Data Collection: Jibril collects only the metadata necessary for effective monitoring and detection. This includes information like file paths, process identifiers, and network flow details, avoiding the collection of unnecessary or sensitive personal data.

• Event Submission Control:

  • Configurable Printers: The destination of detection events is controlled by the enabled printers. Options include standard output, file logging, the listen.dev dashboard, and optional integrations with OpenAI services.

• OpenAI Plugins:

  • Summarization of Events: For enhanced analysis, Jibril can utilize OpenAI plugins to summarize detection events. These summaries provide concise insights into changes, network flows, and detections without exposing raw data.

  • Data Protection: Events submitted to OpenAI are minimal and authenticated. Temporary files created during the summarization process are ephemeral and deleted after use, ensuring that no persistent or sensitive data is stored externally.

• Data Anonymization:

  • Future Implementation: While anonymization features are not currently implemented, they are planned for future releases. These features will further enhance privacy protections by obscuring personal identifiers in the collected data.

• Data Encryption:

  • Planned Enhancements: Future updates may include encryption of data within kernel space and user space, particularly for deployments requiring heightened security measures.

6.2 Security of Submitted Data

• API Authentication:

  • Secure Submissions: Detection events sent to external systems, such as the listen.dev dashboard or OpenAI services, are protected by strong authentication mechanisms. This includes the use of API keys or tokens, ensuring that only authorized data is accepted.

• Secure Transmission:

  • Encrypted Channels: Data is transmitted over secure channels, such as HTTPS, to prevent interception or tampering during transmission.

• Data Minimization:

  • Limited Data Exposure: Only essential information is included in submissions to external systems, reducing the risk associated with data leakage.

6.3 Auditing and Logging

• Comprehensive Audit Logs:

  • Detailed Logging: Jibril maintains detailed logs of actions, events, and detections. These logs provide a robust audit trail that can be used for compliance verification, forensic analysis, or troubleshooting.

• Trace Mode:

  • Enhanced Observability: An optional TRACE mode provides detailed observability of Jibril's operations, including function names, package names, and line numbers.

  • Controlled Activation: TRACE mode is disabled by default and must be explicitly enabled, preventing unnecessary exposure of internal operations.

6.4 External Data Store Integration

• Scalability and Security:

  • Kafka-Backed Dashboards: Integration with systems like the listen.dev dashboard, which is backed by Kafka, allows for scalable and efficient handling of detection events.

  • Secure Integrations: Data sent to external systems is secured through authenticated APIs, ensuring that integrations do not compromise data integrity or security.

6.5 GDPR and Regulatory Alignment

• GDPR Compliance:

  • Data Protection Principles: Jibril's data collection practices align with GDPR principles by minimizing data collection and avoiding personal data where possible.

  • Anonymization and Justification: Future features will include data anonymization, and any processing of sensitive data will be justified and documented to comply with GDPR requirements.

• ISO 27001 Considerations:

  • Strong Security Foundation: Jibril's security mechanisms, including access control, tamper detection, and comprehensive logging, provide a strong foundation for alignment with ISO 27001 standards.

  • Future Certification: Formal documentation and processes can be developed to pursue ISO 27001 certification if required by deployment environments.

7. Summary

Jibril is a state-of-the-art runtime security tool that leverages the power of eBPF to deliver precise and efficient behavioral monitoring without compromising system performance. By employing a query-driven model and avoiding traditional event-streaming mechanisms, Jibril minimizes data loss and reduces the overhead associated with high-throughput, real-time contexts.

Its modular design integrates built-in plugins grouped by detection mechanisms, ensuring maintainability, resilience, and fault isolation. Printers enable flexible event dispatch to secure endpoints, including the listen.dev dashboard and optional OpenAI-powered summaries. Jibril's architecture balances operational transparency, security, and adaptability, making it a trusted solution for modern runtime security needs.

Current features focus on data integrity, strict access control, and robust authentication mechanisms. Future enhancements will introduce data anonymization and encryption, aligning the tool further with GDPR and ISO 27001 standards.

Jibril's comprehensive security model addresses key threats and challenges in runtime security, providing organizations with a robust and adaptable solution for protecting their systems.

Create a Configuration File

$ mkdir /etc/jibril

$ vi /etc/jibril/config.yaml

Use the default configuration file as reference.

Obtain the Image

$ docker pull garnetlabs/jibril:v1.5

Run Jibril using Docker

$ docker run --rm --name=jibril --privileged \
    --pid=host --cgroupns=host --network=host \
    -e TERM=xterm -v /sys:/sys:ro \
    -v /sys/fs/bpf:/sys/fs/bpf:rw \
    -v /etc/jibril/:/etc/jibril:rw \
    -v /var/log/jibril:/var/log/jibril:rw \
    garnetlabs/jibril:v1.5 --config /etc/jibril/config.yaml

This command is an example of how one can run Jibril using its docker image.

Overview

Jibril is a modular runtime security tool that combines an eBPF loader and a userland daemon to monitor, detect, and respond to system behaviors. Its design emphasizes extensibility through plugins, printers, and events, all controlled by a centralized configuration file. This architecture ensures flexibility while maintaining a low resource footprint.

1. Key Components

1.1 eBPF Loader

The eBPF loader is the foundation of Jibril's kernel-level operations. It is responsible for:

• Binary Generation: Creating binaries that include one or more extensions.

• Extensibility: Adding new features by introducing additional files to the source tree.

• Core Role: Acting as both the primary loader and the default extension in the current implementation.

The loader ensures kernel-level data collection with efficiency and scalability.

1.2 Userland Daemon

The userland daemon processes the data collected by the eBPF loader and provides flexible integration points. It comprises several key components:

• Extensions: Define core features and integrations.

• Plugins: Perform specific detection or monitoring tasks.

• Printers: Handle the output of data or events to logs, dashboards, or files.

• Events: Capture and dispatch system behaviors or conditions.

The daemon enables or disables these components based on user configuration, allowing Jibril to adapt to different environments and workloads.

2. Execution Flow

Jibril components follow a structured execution order:

1. Initialization: Core libraries and packages are initialized first.

2. Extensions: Load features like configuration or data storage logic.

3. Plugins: Execute monitoring or detection tasks.

4. Printers: Process and output event data.

5. Events: Dispatch captured behaviors to active printers.

Each component runs through five lifecycle stages: init, start, execute, finish, and exit, ensuring stability and clear state management.

3. Modular Design: Plugins, Printers, and Events

3.1 Plugins

Plugins add specialized functionality to Jibril, focusing on monitoring, detection, and system analysis. All plugins can be enabled or disabled in the configuration file. Examples include:

• Hold: Keeps Jibril running until receiving a termination signal (e.g., SIGSTOP).

• Procfs: Reads data from existing processes in /proc, allowing Jibril to analyze both historical and real-time process activity.

• Net: Monitors network flows, capturing details about active connections and traffic.

• Detect: Provides extensive detection capabilities, such as monitoring file modifications, unauthorized code execution, and suspicious network activity.

• GitHub: Integrates with GitHub repositories to summarize pull requests or changes.

3.2 Printers

Printers define how and where events are output. They are highly configurable and support various endpoints, including:

• Stdout: Prints event data directly to the console for immediate visibility.

• Varlog: Outputs events to log files in /var/log for persistent storage.

• Listendev: Sends data to the dashboard.listen.dev for real-time visualization.

• Datakeeper: Maintains a recent history of events in memory for quick lookups by other components.

Some printers like datakeeper are used as infrastrucure for other components, not as regular event-dispatching printers.

3.3 Events

Events represent system behaviors or states that Jibril monitors and processes. They are the core of Jibril's detection and response capabilities. Examples include:

• Network Monitoring Events:

  • jibril:net:flow: Captures detailed information about active network flows.

  • jibril:netpolicy:dropip: Flags traffic dropped due to IP-based policies.

• Detection Events:

  • File Access:

    • jibril:detect:capabilities_modification: Detects changes to file capabilities.

    • jibril:detect:credentials_files_access: Identifies unauthorized access to sensitive credential files.

  • Execution Monitoring:

    • jibril:detect:hidden_elf_exec Detects hidden ELF binary execution.

    • jibril:detect:binary_executed_by_loader Tracks executions made by ELF loaders.

  • Network Activity:

    • jibril:detect:net_scan_tool_exec Flags usage of network scanning utilities.

    • jibril:detect:net_sniff_tool_exec Identifies execution of network-sniffing tools.

• GitHub Integration Events:

  • jibril:github:pull_summary: Summarizes pull requests.

  • jibril:github:change_summary: Highlights changes in repositories.

With a wide range of events, Jibril allows users to monitor everything from basic system activity to sophisticated threats.

4. Configuration-Driven Behavior

Jibril’s flexibility comes from its configuration file, which governs how components are enabled and interact. Key configurable elements include:

• Log Levels: Control verbosity, ranging from minimal output (fatal) to detailed debugging (debug).

• Daemon Mode: Run Jibril interactively or as a background service.

• Profiling and Health Checks: Enable profiling to debug performance or activate health endpoints for system monitoring.

• Extensions and Plugins: Select which extensions, plugins, and events to load, tailoring Jibril for specific use cases.

• Printers: Define where and how data should be output, such as stdout, log files, or external dashboards.

These options allow Jibril to integrate seamlessly into various operational environments.

5. Why Jibril’s Architecture Works

• Flexibility: Components like plugins, printers, and events can be enabled or disabled, making Jibril highly adaptable.

• Scalability: The modular design allows Jibril to handle small setups or large-scale deployments with ease.

• Efficiency: By using eBPF for kernel-level data collection and a structured userland execution model, Jibril maintains a low resource footprint.

• Comprehensive Monitoring: A wide range of events ensures visibility across network activity, file access, process behavior, and more.

• Integration Ready: Printers and configuration options make it easy to connect Jibril to external systems like dashboards, logs, or custom tools.

Conclusion

Jibril combines the power of eBPF with a modular, extensible framework to deliver advanced runtime security monitoring. Its architecture balances flexibility, efficiency, and ease of use, making it a robust solution for detecting and responding to threats in modern IT environments. Whether monitoring network flows, detecting file access anomalies, or integrating with GitHub workflows, Jibril offers the tools needed to secure your systems effectively.

Distributions

and many others.

Containers

and other container orchestrators (including Incus, LXC/LXD, and others).

CI/CD plugins

The CI/CD integration (plugins) might require:

and other CI/CD orchestrators.

Linux Requirements

• Linux Kernel ≥ v6.2

• x64 Linux OS with eBPF (most current distributions)

• Root privileges with the following capabilities:

  • CAP_BPF (or CAP_SYS_ADMIN if not available)

  • CAP_PERFMON

  • CAP_NET_ADMIN

Kubernetes Requirements

• Kubernetes cluster with version 1.16+

• Command kubectl configured to communicate with your cluster

Obtain Jibril binaries

Run Jibril as a Systemd Service

Jibril can be run as a systemd service.

This is the recommended way to run Jibril in staging/production environments. The following steps will guide you through the installation and configuration of Jibril as a systemd service.

Install the Service

To install the service, run:

This command will create:

The systemd service will be installed, but not enabled yet.

Edit the Configuration File

Edit the configuration file at /etc/jibril/config.yaml. The default configuration enables Jibril with most of its plugins and the detection events.

Enable the Service

After editing the configuration file, enable the service by running:

This will enable the service to start at boot time AND start the service immediately.

Check the Service Status

To check the status of the service, run:

Check the Logs

The varlog printer is enabled by default in the configuration file. This means that the JSON events are printed to /var/log/jibril/events.log, while Jibril stdout and stderr are redirected to systemd journal.

To check the logs, run:

and to check the events, run:

Disable the Service

God forbid, but if you need to disable the service, run:

This will disable the service from starting at boot time AND stop the service immediately.

[Unit]
Description=jibril
Conflicts=example.service
Conflicts=loader.service

[Service]
User=root
#
Type=notify
NotifyAccess=all
RemainAfterExit=no
Restart=no
#
TTYReset=yes
TTYPath=/dev/pts/0
#
Environment=TERM=xterm
Environment=LANG=en_US.UTF-8
Environment=LC_ALL=en_US.UTF-8
Environment=LANGUAGE=en_US.UTF-8
Environment=PATH=/usr/sbin:/usr/bin:/sbin:/bin
Environment=LISTENDEV_DEBUG_PRINTER=/var/log/jibril.events
#
EnvironmentFile=-/etc/default/jibril
EnvironmentFile=-/var/run/jibril/default
#
PrivateTmp=true
PrivateDevices=false
PrivateIPC=false
PrivateMounts=false
PrivateNetwork=false
PrivateUsers=false
#
ExecStartPre=rm -f /var/run/{jibril.pid,jibril.log,jibril.err,jibril.events}
ExecStart=jibril                    \
--notify                            \
--log-level info                    \
--stdout /var/log/jibril.log        \
--stderr /var/log/jibril.err        \
--config /etc/jibril/config.yaml
ExecStopPost=bash -c 'cat /var/log/jibril.err'
#
TimeoutStartSec=300
TimeoutStopSec=600
#
KillMode=control-group

[Install]
WantedBy=multi-user.target

This systemd service file is created automatically.

Deploy Jibril on Kubernetes Clusters

To deploy Jibril as a DaemonSet on Kubernetes clusters, use the setup-k8s.sh script. This script automatically creates a Deployment file with the necessary ConfigMap, DaemonSet, and related resources.

Usage

$ ./setup-k8s.sh [OPTIONS]

Options

Examples

1. Basic deployment with defaults

   Copy

   $ ./setup-k8s.sh

2. Deploy to a custom namespace

   Copy

   $ ./setup-k8s.sh --namespace=monitoring

3. Add node toleration

   Copy

   $ ./setup-k8s.sh --toleration=security-agent:true:NoSchedule

4. Set custom memory limits

   Copy

   $ ./setup-k8s.sh --memory-limit=1Gi --memory-request=512Mi

5. Target specific nodes with a node selector

   Copy

   $ ./setup-k8s.sh --node-selector=role=security

6. Deploy on GPU nodes with higher CPU limits

   Copy

   $ ./setup-k8s.sh --node-selector=gpu=true --cpu-limit=2 --cpu-request=500m

7. Configure multiple tolerations

   Copy

   $ ./setup-k8s.sh --toleration=security:true:NoSchedule --toleration=critical:true:NoExecute

8. Use a custom Jibril configuration file

   Copy

   $ ./setup-k8s.sh --config=/path/to/my-jibril-config.yaml

9. Preview configuration without applying

   Copy

   $ ./setup-k8s.sh --dry-run

10. Save configuration to a custom file

    Copy

    $ ./setup-k8s.sh --output=jibril-prod.yaml

11. Clean up existing deployment

    Copy

    $ ./setup-k8s.sh --cleanup --namespace=security

12. Complete production deployment example

    Copy

    $ ./setup-k8s.sh --namespace=security-prod \
      --image=garnetlabs/jibril:latest \
      --config=/etc/jibril/prod-config.yaml \
      --memory-limit=2Gi \
      --memory-request=1Gi \
      --cpu-limit=1 \
      --toleration=security-monitoring:true:NoSchedule \
      --node-selector=security-tier=high

Notes

Jibril GitHub Plugin

The GitHub plugin interacts with GitHub repositories. This plugin is designed to do the interface between the Jibril runtime security tool, GitHub runners, the GitHub API and Listen.dev's backend.

Summary Events

Jibril uses OpenAI (with a given token) to generate summary events. At the end of its execution, during shutdown, Jibril will generate events with the most important information about the runner execution, after having requested the OpenAI API.

There are 3 types of summary events about the run execution:

Full Summary

A full summary of the runner execution, taking in consideration all existing events and the other summary events. Read: A summary of the summary.

Detections Summary

A summary of the detections made by Jibril during the execution. It uses OpenAI to distingue the most important detections and provide important calls to action.

Flows Summary

A summary of the network flows detected by Jibril during the execution. It uses OpenAI to distingue the most important flows and deviations from what should be considered normal for expected workloads.

And 2 types of summary events about the GitHub pull request itself:

Change Summary

A summary of the changes made in the pull request. If the pull request consists of multiple commits, there will be one change_summary event for each file change, for each existing commit.

Pull Summary

A summary of the pull request itself. It will contain information about the pull request, the commits, the files changed and a parallel to every other event generated by Jibril.

Printers

Listen.dev

The listendev printer is the printer that sends the events to the Listen.dev backend. It needs an account and a token to be used.

Listen.dev Debug

The listendevdebug printer is a debug file for the listendev printer. It is used to debug the listendev printer and should not be used in production environments.

Defaults: /etc/jibril/config.yaml

Run Jibril

Example

Config

Note: There are no plugins in the config extension.

Data

Note: There are no plugins in the data extension.

Jibril

Obtain Jibril binaries

Run Jibril using command line

This command does not show practical results, it is meant to show how Jibril can be executed. It runs the loader (binary named jibril), enables the example, config, data and jibril extensions, the helloworld plugin from the example extension, the hold plugin from the jibril extension, and the datakeeper and varlog printers from the jibril extension.

Select specific components

Jibril footprint can be minimized based on the amount of enabled components. Example:

Jibril will detect the execution of network sniffers and print the events to the stdout.

This command runs the loader (binary named jibril), enables the config, data and jibril extensions, the detect plugin from the jibril extension, the net_sniff_tool_exec event from the detect plugin, and the stdout printer from the jibril extension.

The Network Policy Plugin allows users to define and enforce traffic policies based on CIDRs (IP ranges) and domain resolutions. It supports advanced configurations for alerting, enforcing, and bypassing traffic rules, ensuring flexible network control.

Jibril execution:

sudo -E jibril --log-level info --extension config --extension data --extension jibril --plugin jibril:hold --printer jibril:printers:stdout

Enable the Network Policy Plugin:

--plugin jibril:netpolicy:file=/path/to/policy.yaml

Enable the alert events:

... --event jibril:netpolicy:dropip --event jibril:netpolicy:dropdomain

in case alert or both modes are enabled.

Configuration Example

#
# Alert and deny all traffic by default, allowing only declared domains to be resolved.
#
network_policy:
  #
  # The CIDR mode and policy define the IP address policy. Users can choose to block,
  # alert, enforce, or bypass traffic based on CIDR rules.
  #
  # * "cidr_mode":
  #
  # - "bypass": Allow all traffic.
  # - "alert": Alert on denied traffic to CIDRs or domains.
  # - "enforce": Block denied traffic to CIDRs or domains.
  # - "both": Alert and block denied traffic to CIDRs or domains.
  #
  # * "cidr_policy":
  #
  # - "allow": Allow traffic to CIDRs or domains by default.
  # - "deny": Block traffic to CIDRs or domains by default.
  #
  # As an example, the user might have a default "cidr_policy" set to "deny" and allow all
  # IPs with "cidr" set to "0.0.0.0/0". Then, the user might block an IP with a higher
  # prefix length, such as "9.9.9.9/32".
  #
  cidr_mode: "both"
  cidr_policy: "allow"
  #
  # The RESOLVE mode and policy define the domain resolution policy. Users can block
  # specific domains from being resolved or allow them with alerts.
  #
  # For example, if "resolve_mode" is set to "bypass" but a domain is declared as denied,
  # the resolution will be allowed, but the resolved IPs will be blocked.
  #
  # When "resolve_mode" is enabled (alert, enforce, or both), "resolve_policy" determines
  # whether the resolution should be allowed or denied by default.
  #
  # 1. To be alerted on denied domain resolutions, set "resolve_mode" to "alert" and
  #    "resolve_policy" to "deny". You may still block IPs resolved from specific domains.
  #
  # 2. To block the resolution of denied domains, set "resolve_mode" to "enforce"
  #    and "resolve_policy" to "deny". Be aware that if "mode" is set to "bypass", the
  #    resolution will be disallwed, but direct IP connections to the domain will
  #    still be allowed.
  #
  # * "resolve_mode":
  #
  # - "bypass": Allow all domains to be resolved.
  # - "alert": Alert on denied domain resolutions.
  # - "enforce": Block the resolution of denied domains.
  # - "both": Alert and block the resolution of denied domains.
  #
  # * "resolve_policy":
  #
  # - "allow": Allow domain resolution by default.
  # - "deny": Block domain resolution by default.
  #
  # NOTE: domain rules exist independently of "resolve_mode". If a domain is declared
  #       as "deny", its resolved IPs won't be reachable, regardless of "resolve_mode",
  #       which only controls the resolution process.
  #
  resolve_mode: "bypass"
  resolve_policy: "allow"
  #
  rules:
    # Whitelist Everything (test only).
    # - cidr: "0.0.0.0/0"
    #   policy: "allow"
    # Whitelisted CIDRs (localhost).
    - cidr: "127.0.0.0/8"
      policy: "allow"
    - cidr: "::1/128"
      policy: "allow"
    # Whitelisted CIDRs (internal networks).
    - cidr: "192.168.0.0/16"
      policy: "allow"
    - cidr: "172.16.0.0/16"
      policy: "allow"
    - cidr: "10.0.0.0/8"
      policy: "allow"
    - cidr: "10.0.0.1/32"
      policy: "allow"
    # Whitelisted CIDRs (nameservers).
    - cidr: "8.8.8.8/32"
      policy: "allow"
    - cidr: "8.8.4.4/32"
      policy: "allow"
    - cidr: "1.1.1.1/32"
      policy: "allow"
    - cidr: "9.9.9.9/32"
      policy: "allow"
    # Whitelisted Domains.
    - domain: "org"
      policy: "allow"
    - domain: "google.com"
      policy: "allow"
    # Blacklisted Domains.
    - domain: "example.com"
      policy: "deny"
    - domain: "uol.com.br"
      policy: "deny"

Configuration Overview

Modes and Policies

CIDR Modes

CIDR Policy

Resolve Modes

Resolve Policy

Rule Details

CIDR Rules

Domain Rules

Key Features

• Alert and Enforce Modes Flexibly alert or block traffic and domain resolutions based on custom rules.

• Granular Rule Definition Define specific CIDRs or domains to allow or deny traffic.

• Default Policy Configuration Set default allow or deny policies for both CIDRs and domains.

• Independent Rules Domain resolution rules operate independently of CIDR traffic rules for fine-grained control.

• Testing Support Easily configure test rules, such as whitelisting all traffic, for development and debugging purposes.

Jibril

Jibril (GitHub)

Quick Steps

Script

This is an example of the jibril --features command output. It shows the hierarchy of components available in the Jibril system.

▸ component (none)
▸  ├─┬ packages (package)
▸  │ ├── printers (package)
▸  │ ├── dispatcher (package)
▸  │ ├── cgroups (package)
▸  │ ├── ebpf (package)
▸  │ ├── server (package)
▸  │ ├── settings (package)
▸  │ ├── ebpfobjs (package)
▸  │ └── events (package)
▸  └─┬ extensions (extension)
▸    ├─┬ simple (extension)
▸    │ └─┬ printers (plugin)
▸    │   └── voidprinter (printer)
▸    ├── config (extension)
▸    ├─┬ data (extension)
▸    │ ├── trie (library)
▸    │ └─┬ vmap (library)
▸    │   └── vmap (library)
▸    ├─┬ example (extension)
▸    │ ├── test01 (plugin)
▸    │ ├── test02 (plugin)
▸    │ └── helloworld (plugin)
▸    └─┬ jibril (extension)
▸      ├─┬ tests (test)
▸      │ ├── testtaskargs (test)
▸      │ ├── testtaskflow (test)
▸      │ ├── testallflows (test)
▸      │ ├── testnetpolicy (test)
▸      │ ├── testvmapnest (test)
▸      │ ├── testtaskfile (test)
▸      │ ├── testdomains (test)
▸      │ ├── testfiletask (test)
▸      │ ├── testflows (test)
▸      │ ├── testfiledirbase (test)
▸      │ ├── testtriesuffix (test)
▸      │ └── testvmap (test)
▸      ├─┬ libraries (library)
▸      │ ├── fileprinter (package)
▸      │ ├── utils (library)
▸      │ ├─┬ libfiles (library)
▸      │ │ ├── files (library)
▸      │ │ └── filerefs (library)
▸      │ ├─┬ libnet (library)
▸      │ │ ├── dns (library)
▸      │ │ ├── flows (library)
▸      │ │ └── flowrefs (library)
▸      │ ├─┬ libtasks (library)
▸      │ │ └── tasks (library)
▸      │ └── network (library)
▸      ├─┬ printers (plugin)
▸      │ ├── datakeeper (printer)
▸      │ ├── stdout (printer)
▸      │ └── varlog (printer)
▸      └─┬ plugins (plugin)
▸        ├─┬ netpolicy (plugin)
▸        │ ├─┬ events (plugin)
▸        │ │ ├── dropdomain (event)
▸        │ │ └── dropip (event)
▸        │ └─┬ libraries (library)
▸        │   └── netdrops (library)
▸        ├── procfs (plugin)
▸        ├─┬ detect (plugin)
▸        │ ├─┬ mechanisms (plugin)
▸        │ │ ├── file_access (plugin)
▸        │ │ └── execution (plugin)
▸        │ ├─┬ events (plugin)
▸        │ │ ├─┬ execution (plugin)
▸        │ │ │ ├── code_on_the_fly (event)
▸        │ │ │ ├── net_filecopy_tool_exec (event)
▸        │ │ │ ├── hidden_elf_exec (event)
▸        │ │ │ ├── passwd_usage (event)
▸        │ │ │ ├── runc_suspicious_exec (event)
▸        │ │ │ ├── exec_example (event)
▸        │ │ │ ├── interpreter_shell_spawn (event)
▸        │ │ │ ├── net_suspicious_tool_exec (event)
▸        │ │ │ ├── net_scan_tool_exec (event)
▸        │ │ │ ├── net_suspicious_tool_shell (event)
▸        │ │ │ ├── exec_from_unusual_dir (event)
▸        │ │ │ ├── denial_of_service_tools (event)
▸        │ │ │ ├── file_attribute_change (event)
▸        │ │ │ ├── net_mitm_tool_exec (event)
▸        │ │ │ ├── data_encoder_exec (event)
▸        │ │ │ ├── net_sniff_tool_exec (event)
▸        │ │ │ └── binary_executed_by_loader (event)
▸        │ │ └─┬ fileaccess (plugin)
▸        │ │   ├── credentials_files_access (event)
▸        │ │   ├── os_network_fingerprint (event)
▸        │ │   ├── core_pattern_access (event)
▸        │ │   ├── os_status_fingerprint (event)
▸        │ │   ├── ssl_certificate_access (event)
▸        │ │   ├── code_modification_through_procfs (event)
▸        │ │   ├── capabilities_modification (event)
▸        │ │   ├── package_repo_config_modification (event)
▸        │ │   ├── os_fingerprint (event)
▸        │ │   ├── pam_config_modification (event)
▸        │ │   ├── global_shlib_modification (event)
▸        │ │   ├── java_instrument_lib_load (event)
▸        │ │   ├── shell_config_modification (event)
▸        │ │   ├── sudoers_modification (event)
▸        │ │   ├── file_example (event)
▸        │ │   ├── cpu_fingerprint (event)
▸        │ │   ├── machine_fingerprint (event)
▸        │ │   ├── java_debug_lib_load (event)
▸        │ │   ├── sysrq_access (event)
▸        │ │   ├── sched_debug_access (event)
▸        │ │   ├── unprivileged_bpf_config_access (event)
▸        │ │   └── filesystem_fingerprint (event)
▸        │ └─┬ libraries (library)
▸        │   ├── detection (library)
▸        │   ├── recipe (library)
▸        │   ├── times (library)
▸        │   └── classification (library)
▸        ├─┬ github (plugin)
▸        │ ├─┬ events (plugin)
▸        │ │ ├── detections_summary (event)
▸        │ │ ├── flows_summary (event)
▸        │ │ ├── pull_summary (event)
▸        │ │ ├── summary (event)
▸        │ │ └── change_summary (event)
▸        │ ├─┬ plugins (plugin)
▸        │ │ ├── worksummary (plugin)
▸        │ │ └── pullsummary (plugin)
▸        │ ├─┬ printers (plugin)
▸        │ │ ├── listendevdebug (printer)
▸        │ │ └── listendev (printer)
▸        │ └─┬ libraries (library)
▸        │   ├── environment (library)
▸        │   ├── context (library)
▸        │   ├── tokens (library)
▸        │   ├── steps (library)
▸        │   └── workflow (library)
▸        ├── hold (plugin)
▸        └─┬ net (plugin)
▸          ├─┬ events (plugin)
▸          │ └── flow (event)
▸          └─┬ libraries (library)
▸            └── netflows (library)

Defaults: /etc/jibril/netpolicy.yaml

#
# Alert and deny all traffic by default, allowing only declared domains to be resolved.
#
network_policy:
  #
  # The CIDR mode and policy define the IP address policy. Users can choose to block,
  # alert, enforce, or bypass traffic based on CIDR rules.
  #
  # * "cidr_mode":
  #
  # - "bypass": Allow all traffic.
  # - "alert": Alert on denied traffic to CIDRs or domains.
  # - "enforce": Block denied traffic to CIDRs or domains.
  # - "both": Alert and block denied traffic to CIDRs or domains.
  #
  # * "cidr_policy":
  #
  # - "allow": Allow traffic to CIDRs or domains by default.
  # - "deny": Block traffic to CIDRs or domains by default.
  #
  # As an example, the user might have a default "cidr_policy" set to "deny" and allow all
  # IPs with "cidr" set to "0.0.0.0/0". Then, the user might block an IP with a higher
  # prefix length, such as "9.9.9.9/32".
  #
  cidr_mode: "both"
  cidr_policy: "allow"
  #
  # The RESOLVE mode and policy define the domain resolution policy. Users can block
  # specific domains from being resolved or allow them with alerts.
  #
  # For example, if "resolve_mode" is set to "bypass" but a domain is declared as denied,
  # the resolution will be allowed, but the resolved IPs will be blocked.
  #
  # When "resolve_mode" is enabled (alert, enforce, or both), "resolve_policy" determines
  # whether the resolution should be allowed or denied by default.
  #
  # 1. To be alerted on denied domain resolutions, set "resolve_mode" to "alert" and
  #    "resolve_policy" to "deny". You may still block IPs resolved from specific domains.
  #
  # 2. To block the resolution of denied domains, set "resolve_mode" to "enforce"
  #    and "resolve_policy" to "deny". Be aware that if "mode" is set to "bypass", the
  #    resolution will be disallwed, but direct IP connections to the domain will
  #    still be allowed.
  #
  # * "resolve_mode":
  #
  # - "bypass": Allow all domains to be resolved.
  # - "alert": Alert on denied domain resolutions.
  # - "enforce": Block the resolution of denied domains.
  # - "both": Alert and block the resolution of denied domains.
  #
  # * "resolve_policy":
  #
  # - "allow": Allow domain resolution by default.
  # - "deny": Block domain resolution by default.
  #
  # NOTE: domain rules exist independently of "resolve_mode". If a domain is declared
  #       as "deny", its resolved IPs won't be reachable, regardless of "resolve_mode",
  #       which only controls the resolution process.
  #
  resolve_mode: "bypass"
  resolve_policy: "allow"
  #
  rules:
    # Whitelist Everything (test only).
    # - cidr: "0.0.0.0/0"
    #   policy: "allow"
    # Whitelisted CIDRs (localhost).
    - cidr: "127.0.0.0/8"
      policy: "allow"
    - cidr: "::1/128"
      policy: "allow"
    # Whitelisted CIDRs (internal networks).
    - cidr: "192.168.0.0/16"
      policy: "allow"
    - cidr: "172.16.0.0/16"
      policy: "allow"
    - cidr: "10.0.0.0/8"
      policy: "allow"
    - cidr: "10.0.0.1/32"
      policy: "allow"
    # Whitelisted CIDRs (nameservers).
    - cidr: "8.8.8.8/32"
      policy: "allow"
    - cidr: "8.8.4.4/32"
      policy: "allow"
    - cidr: "1.1.1.1/32"
      policy: "allow"
    - cidr: "9.9.9.9/32"
      policy: "allow"
    # Whitelisted Domains.
    - domain: "org"
      policy: "allow"
    - domain: "google.com"
      policy: "allow"
    # Blacklisted Domains.
    - domain: "example.com"
      policy: "deny"
    - domain: "uol.com.br"
      policy: "deny"

Run Jibril

sudo -E ./build/loader --config /etc/jibril/config.yaml

making sure that the config.yamlfile has:

- jibril:netpolicy:file=/etc/jibril/netpolicy.yaml

configured correctly.

License Issuer: GARNET LABS INC. License Type: MIT-BR: MIT-Binary-Restricted License Registered Address: Ontario, Canada Copyright Year: 2025 Software: Jibril

Overview

This license governs the use of Jibril, distributed exclusively as a compiled binary. Jibril is a runtime security tool developed by Garnet Labs Inc., a corporation registered in Ontario, Canada, and consists of three main projects: Jibril eBPF programs, Jibril eBPF Loader, and Jibril Agent. Jibril is designed for internal use only (non-GPLv2 binary, containing packaged GPLv2 ELF objects) and deployment within user and customer environments across various scenarios, including:

• CI/CD Security Security integration into development pipelines to identify vulnerabilities prior to production.

• Cloud Native Runtime Security for cloud-native applications in containers, Kubernetes, and serverless environments.

• Classic Runtime Runtime security for traditional server environments, focusing on mission-critical applications.

• IoT Security Protection for connected devices and IoT infrastructure in resource-constrained environments.

Jibril is provided as-is, with no warranties or support obligations from Garnet Labs Inc. unless explicitly stipulated in a separate, signed contract. The binary distributes components of multiple projects from a single file.

Licensing Framework

Jibril compiled binary is distributed under the MIT-Binary-Restricted License (MIT-BR). Here’s the breakdown of licenses for its components:

• eBPF Objects: Licensed under GNU General Public License (GPLv2) due to Linux kernel integration. These are uncompressed, loaded into the kernel, and align with licensing norms of similar eBPF projects.

• Userland eBPF Loader and Agent: Licensed under the MIT-Binary-Restricted License (MIT-BR) and statically linked with libbpf, which carries a dual LGPLv2.1 OR BSD-2-Clause license. Any modifications to libbpf will be submitted as proposals to its upstream repository.

The final binary merges these projects into one executable, governed exclusively by MIT-BR for usage terms (see clarification Terms below). However, the embedded eBPF objects remain subject to GPLv2.

License Terms

MIT-Binary-Restricted License

Copyright (c) 2025 Garnet Labs Inc.

Permission is hereby granted, free of charge, to any person or entity obtaining a copy of this software in binary form (the "Software"), to use the Software solely for internal purposes within the licensee's organization or as an individual, subject to the following conditions:

• Internal Use Restriction: The Software is restricted to internal use only. Distribution, publication, sub-licensing, or disclosure of the Software, in whole or in part, to any third party is prohibited without prior written consent from Garnet Labs Inc. This includes any attempt to reverse-engineer, decompile, or disassemble the Software to derive source code or other information, except as permitted by applicable law.

• Embedded Components: The Software includes eBPF objects licensed under the GNU General Public License (GPLv2). Usage of these components remains subject to GPLv2 terms, including source code disclosure obligations if modified and distributed. The Userland eBPF Loader is statically linked with libbpf (dual-licensed under LGPLv2.1 OR BSD-2-Clause); any modifications to libbpf will be proposed to its upstream repository.

The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. IN NO EVENT SHALL GARNET LABS INC. BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Terms of Use

• Scope This license applies to Jibril for internal use within the specified deployment scenarios.

• Distribution Jibril is provided as a binary-only product, with no source code included.

• Support and Liability No support, maintenance, or liability is provided by Garnet Labs Inc. unless specified in a separate, signed contract. The Software is offered as-is, with all risks borne by the licensee.

• Additional Agreements Any obligations, including support during Toronto business hours (9 AM–5 PM ET) or feedback requirements, require a parallel contract with Garnet Labs Inc.

Delivery Specifications

• Binary Format: Jibril is distributed as a single statically linked binary to facilitate distribution. eBPF objects are uncompressed in a local temporary directory and loaded into the kernel.

Contact Information

For inquiries related to licensing or potential contracts, contact Garnet Labs Inc. at jibril@garnet.ai. No response is guaranteed unless a signed agreement is in place.

Last updated: April 1, 2025

Quick Explanation

The capabilities_modification recipe detects changes to the capabilities configuration files. This event is critical as it involves potential defense evasion tactics where attackers may alter system configurations to manage special privileges, potentially leading to escalated privileges or unauthorized actions without triggering standard security alerts.

More Information

Information

Description: Capabilities file modification Category: Defense Evasion Method: Modify System Image Importance: Critical

Analysis of the Event

The capabilities_modification event is triggered when modifications occur in the capabilities configuration files within a Linux environment, specifically targeting changes to /etc/security/capability.conf. This event is significant as it involves potential defense evasion tactics where an attacker or malicious process attempts to alter system configurations that manage special privileges for executing files and commands. Such alterations can significantly impact the security posture of the system.

The use of file access mechanisms for this detection aligns with monitoring critical configuration files, which if improperly modified, could allow escalated privileges or unauthorized actions without triggering standard security alerts. This method falls under modifying the system image, a technique often used by adversaries to persist on a system or evade defenses by altering system configurations that are not typically monitored.

In line with MITRE ATT&CK framework techniques such as T1086 (Taint Library), attackers can exploit vulnerabilities in the capabilities configuration files to bypass security controls. This could involve DNS tunneling for data exfiltration, covert channels for command and control communication, or supply chain risks where trusted software is compromised at an earlier stage of development.

In conclusion, this detection highlights an essential security control within CI/CD pipelines and runtime environments that focus on maintaining the integrity of system configurations. It acts as both a preventive and detective control mechanism against unauthorized changes that could facilitate broader attack campaigns or system compromises.

Implications

Implications for CI/CD Pipelines

Detecting unauthorized modifications to capability configuration files during CI/CD processes suggests an attempt to alter how applications and scripts gain necessary permissions on a host machine. If such changes were merged into production environments, it could lead to applications running with higher privileges than required, potentially resulting in escalated attacks or breaches. This scenario underscores the importance of rigorous code review processes and automated checks like Jibril in identifying and mitigating such risks before deployment.

Implications for Staging

In staging environments, adversarial testing can reveal vulnerabilities that may not be apparent in development phases but are critical before production deployment. Risks include data leakage through insecure configurations or insider threats where unauthorized users gain elevated access to sensitive information. Ensuring robust monitoring and logging of system configuration changes is crucial for detecting such risks early.

Implications for Production

In the production environment, long-term persistence risks become more pronounced as attackers may leverage modified capabilities files to maintain a foothold within the network. Lateral movement becomes easier if an attacker gains elevated privileges, leading to credential theft and data exfiltration. Advanced persistent threats (APT) often exploit such vulnerabilities for extended periods without detection.

Recommended Actions

Actions for CI/CD Pipelines

1. Review and Audit: Immediately review the recent changes in the CI/CD pipeline configurations and scripts that interact with /etc/security/capability.conf. Identify who made the changes and whether they were authorized.

2. Enhance Security Checks: Integrate additional security scanning tools that specifically check for unauthorized changes to critical configuration files during the build and deployment process.

3. Update Change Management Policies: Ensure that any changes to critical system files like capability.conf are subjected to strict review processes and require approval from multiple team members.

4. Educate and Train: Conduct training sessions for developers and operations teams on the importance of secure handling of system configuration files and the potential risks associated with unauthorized modifications.

Actions for Staging

1. Monitor and Log Changes: Implement robust monitoring tools that log all changes made to system configuration files in real-time. This will help in quickly identifying and responding to unauthorized modifications.

2. Conduct Security Audits: Regularly schedule security audits in the staging environment to check for compliance with security policies and the integrity of system configurations.

3. Simulate Attacks: Perform red team exercises focusing on the exploitation of modified capabilities files to understand potential attack vectors and improve defensive strategies.

Actions for Production

1. Immediate Incident Response: Initiate an incident response protocol to assess the extent of the modification and its impact on the production environment. Isolate affected systems to prevent further unauthorized access or damage.

2. Forensic Analysis: Conduct a thorough forensic analysis to determine the source and method of the modification. This will help in understanding the attack vectors and in preventing future incidents.

3. Restore from Backup: If necessary, restore the affected configuration files from a secure backup after ensuring that the backup is free from any tampering or malicious modifications.

4. Continuous Monitoring: Enhance continuous monitoring capabilities to detect and alert on any unauthorized changes to critical system files immediately.

Quick Explanation

The auth_logs_tamper detection recipe identifies suspicious file operations such as removal or truncation of critical system authentication logs. These actions may indicate attempts to conceal malicious activity, making it harder for defenders to detect intrusions and understand the timeline of events.

More Information

Information

Description: Authentication logs tampering Category: Defense Evasion Method: Indicator Removal on Host Importance: High

Analysis of the Event

The auth_logs_tamper detection event, as identified by Jibril, triggers when file removal or truncation operations are performed on key authentication and logging files. These actions can be indicative of an adversary attempting to obscure their presence within a system. Logs such as /var/log/secure, /var/log/wtmp, and /var/log/btmp are critical for maintaining audit trails that help in identifying unauthorized access, privilege escalation attempts, or other malicious activities.

From the perspective of the MITRE ATT&CK framework, this event aligns with techniques categorized under Defense Evasion. Specifically, it falls under the subcategory of "Indicator Removal on Host," where adversaries remove or manipulate forensic evidence to avoid detection. In a CI/CD pipeline context, log tampering can be particularly dangerous as it can mask unauthorized changes or malicious code introduced during build processes. By eliminating or corrupting logs, attackers can remain undetected and potentially persist within systems or applications, complicating forensic investigations.

At a deeper level, removing or truncating authentication logs not only invalidates critical forensics data but also disrupts normal auditing procedures. This tactic is often combined with other methods such as lateral movement (T1021) or privilege escalation (T1055), allowing attackers to quietly expand their foothold within the environment while remaining under the radar of standard security monitoring tools.

Implications

Implications for CI/CD Pipelines

In the context of CI/CD pipelines, the detection of authentication logs tampering raises significant concerns about the integrity of the build and deployment processes. If left unaddressed, this event could indicate that an attacker has gained unauthorized access to the pipeline and is attempting to conceal their activities by removing or altering critical logs. This could lead to the deployment of malicious code into production environments, potentially resulting in data breaches, service disruptions, or unauthorized access to sensitive information.

Implications for Staging

In staging environments, authentication logs tampering can have serious implications for the security of the deployment pipeline. Adversaries may exploit this tactic to cover their tracks and maintain persistence within the environment, potentially leading to unauthorized access, data exfiltration, or further compromise of production systems. Detecting and responding to log tampering in staging environments is crucial to prevent the escalation of attacks and protect the integrity of the deployment process.

Implications for Production

In production environments, the tampering of authentication logs poses a significant risk to the security and availability of critical systems. By removing or truncating these logs, attackers can evade detection, cover their tracks, and maintain persistent access to sensitive resources. This can lead to unauthorized data access, privilege escalation, or other malicious activities that could have severe consequences for the organization. Detecting and responding to log tampering in production environments is essential to prevent further compromise and protect critical assets.

Recommended Actions

Actions for CI/CD Pipelines

1. Audit and Review: Immediately audit all recent changes and deployments to identify any unauthorized or suspicious activity. Review the integrity of the codebase and check for any unauthorized modifications or additions.

2. Access Control: Review and tighten access controls around the CI/CD pipeline. Ensure that only authorized personnel have the ability to make changes to the pipeline and related systems.

3. Forensic Analysis: If tampering is confirmed, conduct a thorough forensic analysis to understand the scope of the breach and identify the methods used by the attacker. This will help in strengthening the defenses against future attacks.

Actions for Staging

1. Immediate Isolation: Temporarily isolate the staging environment from other network segments to prevent potential lateral movement or further compromise.

2. Comprehensive Scan: Perform a comprehensive security scan of the staging environment to check for any signs of compromise or residual malicious activity.

3. Restore Logs: Restore the tampered logs from backups, if available, to regain visibility into recent activities and help in the investigation process.

4. Security Review: Conduct a security review of the staging environment setup, focusing on access controls, monitoring capabilities, and incident response procedures.

Actions for Production

1. Incident Response Activation: Activate the incident response plan and assemble the response team to address the detected tampering event.

2. Log Analysis: Utilize backup logs or any existing forensic data to analyze the activities prior to the tampering incident. This can provide insights into the attacker’s actions and objectives.

3. System-Wide Audit: Conduct a system-wide audit to check for any further signs of compromise, unauthorized access, or other anomalies in the production environment.

4. Communication: Keep stakeholders informed about the situation and the steps being taken to resolve the issue, maintaining transparency and trust.

Quick Explanation

The binary_self_deletion detection recipe identifies instances where a binary file is executed and then promptly unlinked (deleted) from the filesystem. This behavior often indicates defense evasion tactics employed by attackers to conceal malicious operations by removing artifacts immediately after execution, which can expose systems to unauthorized access, tampering, or persistence mechanisms if not properly mitigated.

More Information

Information

Description: Binary executed and self-deleted Category: Defense Evasion Method: Indicator Removal on Host Importance: Critical

Analysis of the Event

The binary_self_deletion detection, flagged by Jibril, highlights a critical defense evasion method where a binary executes and then self-deletes. This behavior is particularly concerning as it indicates an attempt to erase traces of execution, thereby hindering forensic analysis and post-incident investigation efforts.

From a security perspective, this tactic aligns with the MITRE ATT&CK framework's defense evasion techniques under T1070 (Indicator Removal on Host). Such methods are often employed by attackers to execute malicious payloads that operate only in memory, leaving no trace on disk. This approach makes detection by traditional file-based antivirus solutions challenging and can facilitate advanced persistent threats (APTs).

In legitimate workflows, temporary file creation and deletion may occur, especially in high-performance or ephemeral environments such as containerized applications. However, the deliberate unlinking of an executed binary requires careful scrutiny, particularly in CI/CD pipelines where trust boundaries are critical.

Implications

Implications for CI/CD Pipelines

The detection of this behavior during a CI/CD pipeline run indicates a potential risk introduced by recent code changes. If left unchecked, merging such changes into production could result in malicious artifacts operating covertly within the infrastructure, bypassing detection mechanisms. This may lead to significant consequences, including data breaches, privilege escalation, and unauthorized persistence within the system. The detection emphasizes the need for stringent controls and monitoring in CI/CD environments to mitigate risks associated with transient binaries.

Implications for Staging

In staging environments, adversarial testing can reveal vulnerabilities that might be exploited by attackers. Data leakage from staging environments could lead to insider threats or unauthorized access before production deployment. Detecting binary self-deletion is crucial as it may indicate the presence of malicious actors who are attempting to evade detection and maintain persistence across different stages of the development lifecycle.

Implications for Production

In a production environment, the long-term persistence risks associated with binary self-deletion include lateral movement within the network, credential theft, data exfiltration, and APTs. Attackers may use this technique to deploy malware that operates only in memory, leaving no trace on disk and making detection by traditional file-based antivirus solutions challenging. This can lead to sustained access to critical systems and sensitive information.

Recommended Actions

Actions for CI/CD Pipelines

1. Review Recent Code Changes: Immediately review all recent commits and merge requests for any unusual or unauthorized modifications that could introduce self-deleting binaries.

2. Enhance Monitoring and Logging: Implement or enhance logging of all file operations, especially execution and deletion events, to help trace the origin of such behaviors.

3. Conduct a Security Audit: Perform a thorough security audit of your CI/CD pipeline to ensure there are no vulnerabilities that could be exploited to introduce malicious code.

4. Update Security Policies: Revise and strengthen security policies and access controls to limit who can push code changes and under what conditions.

Actions for Staging

1. Perform In-depth Forensic Analysis: Conduct a detailed forensic analysis to understand the source and intent of the self-deleting binaries.

2. Isolate Affected Systems: Immediately isolate systems where the binary self-deletion was detected to prevent potential spread or escalation.

3. Verify Integrity of Staging Data: Ensure that all data in the staging environment is intact and has not been tampered with or exfiltrated.

4. Strengthen Staging Environment Security: Implement stricter security measures in the staging environment, including more rigorous monitoring and access controls.

Actions for Production

1. Immediate Incident Response: Initiate an incident response protocol to assess the impact and scope of the issue. This includes isolating affected systems and conducting a thorough investigation.

2. Notify Relevant Stakeholders: Inform IT security teams, management, and potentially affected clients or partners about the breach to maintain transparency and trust.

3. Restore from Known Good Backups: If malicious activity is confirmed, restore affected systems from backups that are verified to be free of the malicious binaries.

4. Continuous Monitoring and Improvement: After addressing the immediate threat, implement continuous monitoring solutions to detect similar threats in the future and continuously improve defense mechanisms based on the latest threat intelligence.

Quick Explanation

The code_modification_through_procfs event is a critical security issue that detects attempts at modifying code via the proc filesystem. This technique, often used in defense evasion and malicious activities, allows attackers to inject malicious payloads into running processes without being detected by traditional monitoring systems, leading to potential privilege escalation and persistent access.

More Information

Information

Description: Code modification through procfs Category: Defense Evasion Method: Impair Defenses Importance: High

Analysis of the Event

This event is triggered when there are attempts to modify code by accessing process memory directly via the /proc filesystem, a tactic frequently employed in defense evasion and malicious activities. The proc filesystem (/proc) on Linux systems provides an interface for accessing kernel data structures and information about system processes. It allows users to read and write to files that represent running processes, including their memory spaces.

Attackers exploit this feature by writing directly into the memory space of a process through paths like /proc/[pid]/mem. This technique is particularly dangerous because it can bypass conventional file integrity monitoring systems since no actual files are modified on disk. Instead, the changes occur in memory, allowing for stealthy execution of arbitrary code with elevated privileges.

This type of attack aligns closely with several MITRE ATT&CK tactics and techniques, specifically under the Defense Evasion (TA0005) tactic. It involves techniques such as Modify System Processes (T1087), which refers to modifying running processes to evade detection, and Process Injection (T1055), which involves injecting malicious code into legitimate processes.

Implications

Implications for CI/CD Pipelines

The risk of build process compromise is heightened due to potential dependency poisoning or artifact integrity issues. Attackers might inject malicious code during the build phase, leveraging /proc filesystem access to manipulate running processes without leaving traces in source control systems. This can lead to undetected vulnerabilities being introduced into production environments.

Implications for Staging

In staging environments, adversarial testing poses significant risks as attackers could exploit similar techniques to exfiltrate sensitive data or establish a foothold before the final deployment. Unauthorized access and insider threats are also concerns, as these environments often contain valuable information that can be leveraged for further attacks on production systems.

Implications for Production

The implications in production are severe, including long-term persistence risks where attackers maintain unauthorized access by injecting malicious code into critical processes. Lateral movement becomes easier due to elevated privileges, and credential theft can lead to broader infrastructure compromise. Advanced Persistent Threats (APTs) often use such techniques to remain undetected for extended periods.

Recommended Actions

Actions for CI/CD Pipelines

1. Audit and Monitor Access: Implement strict monitoring on the /proc filesystem to detect any unauthorized access or modifications. Use tools that can track and alert on direct memory access patterns.

2. Enhance Security Controls: Integrate security tools that specifically check for memory-based manipulations during the build process. Consider using runtime security tools that can detect unusual process behaviors.

3. Review and Harden Build Scripts: Regularly review build scripts and environments for any signs of tampering. Harden access controls to build servers and restrict who can modify the environment.

4. Continuous Security Training: Educate your development and operations teams about the risks associated with the /proc filesystem and the importance of secure coding practices.

Actions for Staging

1. Simulate Attacks: Regularly perform security testing, including penetration testing and red team exercises, focusing on memory manipulation techniques to identify potential vulnerabilities.

2. Implement Tighter Access Controls: Restrict access to the staging environment, ensuring only authorized personnel can interact with critical processes and the filesystem.

3. Use Canary Tokens: Deploy canary tokens or other tripwire techniques in the staging environment to detect and alert on unauthorized access attempts.

4. Regular Security Audits: Conduct frequent security audits of the staging environment to ensure compliance with security policies and to detect any potential security lapses.

Actions for Production

1. Real-Time Threat Detection: Deploy advanced threat detection systems that can analyze and flag unusual memory and process behaviors in real time.

2. Forensic Analysis: In the event of a detection, immediately perform a comprehensive forensic analysis to understand the scope and impact of the intrusion.

3. Incident Response Plan: Ensure that an incident response plan is in place and regularly updated to handle cases of code modification through procfs effectively.

4. Patch and Update Systems: Regularly update and patch systems to protect against known vulnerabilities that could be exploited through the /proc filesystem.

Jibril (Net)

Jibril (NetPolicy)

Jibril (Detect)

Mechanism: File Access

Mechanism: Execution