LoFP LoFP / linux

linux rule

TitleTags
admin activity
admin activity (especially in /tmp folders)
admin changing date of files.
admin or user activity
admin or user activity are expected to generate some false positives
admin work like legit service installs.
administrative activity
administrative work
administrator interacting with immutable files (e.g. for instance backups).
administrator or administrator scripts might delete packages for several reasons (debugging, troubleshooting).
administrators or developers may execute kubeletctl during legitimate troubleshooting or incident response to validate kubelet api connectivity or enumerate pods. confirm the user/session and change window before escalating.
administrators or installed processes that leverage nohup
administrators reading kubeconfig or cloud profiles during migration can match; correlate with change tickets and bastion sessions.
an administrator troubleshooting. investigate all attempts.
any user deleting files that way.
appending null bytes to files.
automated tools such as jenkins may encode or decode files as part of their normal behavior. these events can be filtered by the process executable or username values.
backup, configuration management, and image scanners may open the same paths from scripted utilities; baseline trusted agents and narrow exclusions by process executable hash or parent chain.
base images, entrypoints, or init wrappers may legitimately invoke curl or wget during container startup (package installs, health checks); baseline trusted images and exclude stable image digests or namespaces when noisy.
base64 encoded data in log entries
build and packaging images sometimes run chroot against a staged root filesystem inside ci or init containers; correlate with approved pipelines and image build jobs before escalating.
certain programs or applications may modify files or change ownership in writable directories. these can be exempted by username.
certain tools may create hidden temporary directories upon installation or as part of their normal behavior. these events can be filtered by the process arguments, username, or process name values.
certain tools may create hidden temporary files or directories upon installation or as part of their normal behavior. these events can be filtered by the process arguments, username, or process name values.
certain tools or automated software may enumerate hardware information. these tools can be exempted via user name or process arguments to eliminate potential noise.
cluster operators and node diagnostics may legitimately probe kubelet endpoints (for example /pods or /metrics) during troubleshooting. validate the initiating user, session, and whether the target node/ip is expected for the host.
cluster provisioning (kubeadm), configuration management, or administrators editing manifests during maintenance may match. baseline approved automation and interactive admin sessions on control plane nodes.
command line contains daemon-reload.
container runtimes or security tools during initialization
crazy web applications
creation of legitimate files in sudoers.d folder as part of administrator work
credential reads under non-root home trees are intentionally excluded; clone the rule with explicit per-user file.path values and optional process.executable prefixes if you must cover interactive accounts with matching audit -w lines for those paths.
custom administrative wrappers or hardened images that legitimately ship a setuid shell outside /usr/bin or /bin for emergency access may match; document and exclude by executable hash or path when verified.
custom container tooling, ci agents, or monitoring may connect to docker.sock or containerd.sock from non-standard paths after relocation or bind mounts. tune by process.executable or user.name when noise is high.
debugging or legitimate software testing
debugging scripts
developer-oriented containers and ci build pods can run curl/wget from pid 1 descendants under runc; correlate with build pipelines and approved registries.
device creation by legitimate scripts or init systems (udevadm, makedev)
directories /dev/shm and /run/shm are temporary file storage directories in linux. they are intended to appear as a mounted file system, but uses virtual memory instead of a persistent storage device and thus are used for mounting file systems in legitimate purposes.
false positives are expected to be very rare due to the specific nature of this rule. legitimate application deployments typically do not involve multipart form uploads to .action endpoints followed immediately by jsp file creation in webapps directories. however, custom deployment scripts or automated testing tools that simulate file uploads could potentially trigger this alert. review the source ip, user agent, uploaded file content, timing, and deployment schedules to validate if the activity is authorized. standard package manager operations are already excluded from detection.
false-positives (fp) can appear if the pid file is legitimate and holding a process id as intended. to differentiate, if the pid file is an executable or larger than 10 bytes, it should be ruled suspicious.
false-positives (fp) should be at a minimum with this detection as pid files are meant to hold process ids, not inherently be executables that spawn processes.
field mapping differences between auditd versions can occasionally mis-populate effective versus real user ids; validate raw audit fields when triaging unexpected hits.
github operations such as ghe-backup
installation of legitimate service.
installer scripts or automated provisioning tools
legitimate activities
legitimate activity of system administrators
legitimate admin activity
legitimate administration activities
legitimate administrative activities
legitimate administrative tasks or scripts that use 'sudo --chroot' for containerization, testing, or system management.
legitimate administrative tasks, package managers, containers, configuration management tools, cloud agents, or system maintenance operations might cause false positives. apply baselining before deployment.
legitimate administrator activities
legitimate administrator or user uses network sniffing tool for legitimate reasons.
legitimate af_alg usage from unprivileged users is uncommon, but some kernel crypto tests, ipsec helpers, disk encryption tooling, hsm integrations, or approved security research systems may exercise this interface. verify the process, user, and host role before adding an exception.
legitimate backup, compliance scanners, or admin scripts that enumerate paths under /home or /var/run/secrets may match. tune by parent process, image, or automation identity.
legitimate cases in which \"rsync\" is used to execute a shell
legitimate downloads of files in the tmp folder.
legitimate files with similar naming patterns (very unlikely).
legitimate modification of crontab
legitimate node health checks, diagnostics, or in-cluster agents may access the kubelet api on port 10250. validate the calling process, command line, and whether the destination is the local node or another node.
legitimate overwrite of files.
legitimate ports redirect
legitimate pre-commit hooks or ci/cd pipeline jobs that use a script to run a credential scanner as part of a security check.
legitimate reconfiguration of service.
legitimate sandboxing, container tooling, or maintenance scripts may use unshare and spawn privileged helpers under controlled workflows. baseline approved tools and tune by host role, parent process, or user accounts.
legitimate shell scripts in the \"profile.d\" directory could be common in your environment. apply additional filter accordingly via \"image\", by adding specific filenames you \"trust\" or by correlating it with other events.
legitimate software that uses these patterns
legitimate software, cleaning hist file
legitimate system administrator usage of these commands
legitimate usage of teamviewer
legitimate usage of the unsafe option
legitimate usage of wget utility to post a file
legitimate usage of xclip tools.
legitimate use of archiving tools by legitimate user.
legitimate use of crontab
legitimate use of crypto miners
legitimate use of ngrok
legitimate use of python for decoding data, which is uncommon in typical enterprise environments but possible in development or data analysis contexts.
legitimate use of screenshot utility
legitimate use of scx runasprovider executescript.
legitimate use of scx runasprovider invoke_executeshellcommand.
legitimate use of the localtonet service.
legitimate use of trufflehog by security teams or developers.
legitimate user shell modification activity.
likely
log rotation.
maintenance.
netcat is a dual-use tool that can be used for benign or malicious activity. netcat is included in some linux distributions so its presence is not necessarily suspicious. some normal use of this program, while uncommon, may originate from scripts, automation tools, and frameworks.
network administrators
network monitoring or management products may have a web server component that runs shell commands as part of normal behavior.
normal use of hping is uncommon apart from security testing and research. use by non-security engineers is very uncommon.
other tools that use a --cpu-priority flag
platform automation, node bootstrap, and legitimate break-glass admin sessions may use these clis with overlapping arguments. tune by parent process, user, or host role (worker vs bastion).
platform engineers may nsenter into pid 1 namespaces during deep node debugging; correlate with tickets and bastion sessions before escalating.
rare temporary workaround for library misconfiguration
regular file creation during system update or software installation by the package manager
scripts created by developers and admins
security tools and device drivers may run these programs in order to enumerate kernel modules. use of these programs by ordinary users is uncommon. these can be exempted by process name or username.
some automation or break-glass tooling may invoke suid binaries from scripts under /home; validate parent identity and change tickets before escalating.
some break-glass workflows or automation may legitimately invoke sudo/su from scripts under user home directories. validate the initiating user, parent context, and change approvals; tune by known admin tooling paths or accounts.
some container tools or deployments may use these techniques natively to determine how they proceed with execution, and will need to be filtered
some false positives are to be expected on user or administrator machines. apply additional filters as needed.
some false positives are to be expected. apply additional filters as needed before pushing to production.
some normal use of this command may originate from security engineers and network or server administrators, but this is usually not routine or unannounced. use of `nping` by non-engineers or ordinary users is uncommon.
system administrator manually stopping kaspersky services
system administrators or scripts that intentionally clear logs
system update scripts using temporary files
telnet can be used for both benign or malicious purposes. telnet is included by default in some linux distributions, so its presence is not inherently suspicious. the use of telnet to manage devices remotely has declined in recent years in favor of more secure protocols such as ssh. telnet usage by non-automated tools or frameworks may be suspicious.
testing or development activity
there is a potential for false positives if the container is used for legitimate tasks that require the use of network utilities, such as network troubleshooting, testing or system monitoring. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is usually no reason to remove modules, but some buggy modules require it. these can be exempted by username. note that some linux distributions are not built to support the removal of modules at all.
this rule may trigger in cases where a user has routine work patterns that result in infrequent authentications.
trusted openssh executable updates. it's recommended to verify the integrity of openssh binary changes.
trusted system module updates or allowed pluggable authentication module (pam) daemon configuration changes.
unknown
unlikely
updates to approved and trusted ssh executables can trigger this rule.
user interacting with files permissions (normal/daily behaviour).
web applications that invoke linux command line tools