GCFA Practice Question: Identification of Malicious and Normal Activity
An analyst is triaging a Linux server and finds a process whose /proc/<pid>/exe symlink points to /tmp/.kwork, and whose parent process is the legitimate cron daemon. The file is owned by root but has no package ownership record. Which interpretation is most appropriate?
⚠ Common exam trap
The trap here is trusting the process name, because an attacker can name a binary to mimic a kernel worker while the executable path and package status reveal it is not legitimate.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The process is likely malicious persistence launched by cron from a non-standard, unmanaged path.
An unmanaged root-owned binary in /tmp executed by cron indicates an attacker added a scheduled job to launch a dropped payload. The kernel-thread-style name is a masquerade, since real kernel threads have no on-disk executable. Investigators should dump the crontab entries, hash the binary, and review /var/log/cron and auth logs for the insertion window.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The process is likely malicious persistence launched by cron from a non-standard, unmanaged path.
Why this is correct
A root-owned executable in /tmp that is not tracked by the package manager and is parented by cron strongly suggests an attacker added a cron entry to execute a dropped binary. The name mimics a kernel worker to blend in, but kernel threads lack disk executables. The combination of location, ownership, parent, and missing package record makes a malicious interpretation the most defensible.
- ✗
This is a legitimate kernel worker thread that cron spawned during routine maintenance.
Why it's wrong here
Kernel worker threads appear in brackets in process listings and do not have a backing executable on disk, so /proc/<pid>/exe would not resolve to /tmp/.kwork. The name is designed to look like a kernel thread, which is the deception. Package ownership would also apply to real cron binaries. This interpretation accepts the masquerade at face value.
- ✗
The process is a normal systemd service that was forked by cron after a unit reload.
Why it's wrong here
systemd services are children of PID 1 or of the service manager, not of cron. Their executables live under /usr/lib or /usr/bin and are package-managed. A binary in /tmp with no package record contradicts a systemd service interpretation, and the parent process shown in the stem rules it out outright.
- ✗
The process is a containerized workload placed in /tmp by the container runtime.
Why it's wrong here
Container runtimes such as Docker or containerd place binaries in image layers and overlay filesystems, not in the host /tmp directory, and container processes are typically parented by the runtime shim rather than cron. The ownership, parent process, and missing package metadata do not fit a containerized workload explanation in this scenario.
About these practice questions
One of 292 original GCFA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official GIAC exam blueprint
This GCFA practice question is part of Courseiva's free GIAC certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCFA exam.