How to remediate – YARA Memory Scan (Linux)

1. Introduction

Nessus detected one or more malicious processes on a Linux host, indicating a potential compromise. This vulnerability means an attacker may already have code running with system-level access. It primarily affects Linux servers and workstations. Impact is likely to be high across confidentiality, integrity, and availability if exploitation succeeds.

2. Technical Explanation

Nessus identified processes matching a YARA rule designed to detect known malicious software or behaviours. This indicates the presence of code that has been flagged as suspicious. Exploitation requires a privileged account with access to use ptrace, which allows debugging and memory inspection. An attacker could use this to hide their activity or escalate privileges further.

• Root cause: A process on the system matches a YARA rule indicating malicious characteristics.
• Exploit mechanism: An attacker has already placed code onto the system that is detected by the YARA rule. This code may be running as root or another privileged user.
• Scope: Linux systems with processes matching the identified YARA rules.

3. Detection and Assessment

Confirming a vulnerability requires checking for processes flagged by the YARA scan. A quick check involves reviewing currently running processes, while thorough assessment uses the Nessus results.

• Quick checks: Use `ps aux` to list all processes and look for unusual or unexpected entries.
• Scanning: The Nessus vulnerability detection itself is a primary scanning method.
• Logs and evidence: Examine system logs (e.g., `/var/log/auth.log`, `/var/log/syslog`) for suspicious process creation events.

ps aux | grep 

4. Solution / Remediation Steps

Fixing this issue requires investigating and removing the malicious processes. These steps should be performed carefully to avoid disrupting system functionality.

4.1 Preparation

• Dependencies: Access to command line and root privileges are required. Roll back plan: Restore from the pre-fix backup if issues occur.
• Change window needs: A maintenance window is recommended due to potential service disruption. Approval should be sought from system owners.

4.2 Implementation

1. Step 1: Identify the malicious process ID (PID) using `ps aux` or `top`.
2. Step 2: Use `lsof -p ` to identify any open files associated with the process.
3. Step 3: Kill the process using `kill `.
4. Step 5: Scan the system again with Nessus to confirm removal.

4.3 Config or Code Example

Before

ps aux | grep malicious_process

After

ps aux | grep malicious_process  (no output)

4.4 Security Practices Relevant to This Vulnerability

Practices that directly address this vulnerability type include least privilege and regular system scanning.

• Practice 1: Least privilege reduces the impact if a process is compromised, limiting its access to system resources.

4.5 Automation (Optional)

#!/bin/bash
# This script is for example only. Use with caution.
PID=$(pgrep malicious_process)
if [ -n "$PID" ]; then
  kill $PID
  echo "Process killed."
fi

5. Verification / Validation

Confirm the fix by verifying the process is no longer running and that Nessus reports no further detections.

• Post-fix check: Run `ps aux | grep malicious_process`. Expected output should be empty.
• Re-test: Re-run the Nessus scan to confirm the vulnerability is resolved.
• Smoke test: Verify essential system services are still functioning correctly (e.g., SSH access, network connectivity).
• Monitoring: Monitor `/var/log/auth.log` and `/var/log/syslog` for any new instances of the malicious process or related activity.

ps aux | grep malicious_process (no output)

6. Preventive Measures and Monitoring

Preventive measures include updating security baselines and implementing intrusion detection systems.

• Baselines: Update system security baselines to reflect known malicious behaviours or signatures.
• Pipelines: Integrate vulnerability scanning into CI/CD pipelines to detect issues early in the development lifecycle.
• Asset and patch process: Implement a regular patch management cycle to address known vulnerabilities promptly.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Incorrectly identifying a legitimate process as malicious could lead to service outages.
• Risk or side effect 2: Killing a process without understanding its dependencies may cause unexpected errors.
• Roll back: Restore the system from the pre-fix backup if issues occur.

8. References and Resources

• Vendor advisory or bulletin: N/A – depends on the specific process detected by YARA
• NVD or CVE entry: N/A – YARA detections are often for known malware, but not tied to a single CVE.
• Product or platform documentation relevant to the fix: http://virustotal.github.io/yara/