• ☐
  • INCIDENT REPORT SUSPICIOUS BACKDOOR O **** page size: 5423 bytes

Incident Report: Suspicious Backdoor on a FreeBSD Pubnix Server

Summary

During routine inspection of a FreeBSD pubnix server, I discovered two unusual processes running under a regular user account.

The processes appeared as:

[kswapd0] (defunct)

This was immediately suspicious because kswapd0 is normally associated with the Linux kernel, while the affected system runs FreeBSD.

Further investigation showed that the processes were not kernel threads at all. They were instances of a user-owned executable located at:

~/.config/htop/defunct

The executable maintained an outbound TCP connection to an external host over port 443 and had multiple persistence mechanisms.

The affected account was subsequently disabled and the relevant files were preserved for further investigation.

Discovery

The issue was initially noticed while reviewing processes belonging to non-system users.

Two processes stood out:

USER       PID   PPID  COMMAND
affected   1909     1  [kswapd0] (defunct)
affected   1910  1909  [kswapd0] (defunct)

Inspection with FreeBSD's procstat showed that both processes were actually executing:

~/.config/htop/defunct

The executable was identified as:

ELF 64-bit executable
x86-64
FreeBSD
statically linked
stripped

A SHA-256 hash was recorded for forensic purposes:

7cfbaa38eb655f26b177b41fc0fa2476eef40adc9367c1414f55ccc04cfbeb0a

Network activity

One instance maintained an outbound TCP connection:

local-host:high-port -> remote-host:443

The use of port 443 by itself is not suspicious, but combined with the disguised process name, hidden executable location, and persistence mechanisms, it reinforced the conclusion that this was not normal user activity.

Persistence

Two persistence mechanisms were discovered.

The user's crontab contained an hourly job that checked whether the process was running and relaunched it if necessary.

The command was Base64-encoded and included arguments that caused the executable to start with a misleading process name resembling a Linux kernel thread.

The user's shell profile also contained a similar encoded command, causing the program to start during login.

Both entries contained comments attempting to disguise the commands as pseudo-random-number-generator initialization.

In simplified form, the persistence mechanism effectively did this:

if process_is_not_running; then
    exec -a '[kswapd0]' ~/.config/htop/defunct
fi

A companion file was also present:

~/.config/htop/defunct.dat

This file was preserved along with the executable.

Indicators of compromise

The following indicators were observed:

~/.config/htop/defunct
~/.config/htop/defunct.dat

Process name:

[kswapd0]

Persistence markers included:

#defunct-kernel
GS_ARGS
base64 -d

The executable was deliberately placed in a hidden configuration directory and launched under a misleading name.

Containment

The affected account was treated as compromised.

The following actions were taken:

  • The user account was locked.
  • Interactive login was disabled.
  • SSH access for the account was denied.
  • The user's crontab was removed.
  • All processes owned by the account were terminated.
  • The user's home directory was restricted.
  • The executable, configuration files, crontab, shell profile, and process information were preserved as evidence.
  • Other user accounts were searched for the same executable and persistence patterns.

No identical ~/.config/htop/defunct installation was found under other user accounts during the initial scan.

Scope

At the time of discovery, the evidence confirmed compromise of a single unprivileged user account.

There was no direct evidence from this investigation alone that root privileges had been obtained.

However, because this is a multi-user public Unix system, the incident was treated seriously. A compromised account can still be used for persistent remote access, scanning, credential theft, lateral movement, or attacks against other services and users.

Lessons

The most important lesson from this incident was that process-name masquerading can be surprisingly effective.

At first glance:

[kswapd0]

looks like a kernel-related process.

On a FreeBSD system, however, that name immediately becomes anomalous.

Several other details also helped identify the problem:

  • a kernel-like process owned by a normal user
  • an executable under a hidden configuration directory
  • a stripped, statically linked binary
  • an external network connection
  • Base64-encoded startup commands
  • cron-based persistence
  • shell-profile persistence
  • misleading comments intended to make malicious commands look legitimate

None of these signals alone necessarily proves compromise. Together, they made the situation highly suspicious.

Conclusion

The incident appears to have involved a persistent remote-access program installed under a regular pubnix user account and deliberately disguised as a Linux kernel process.

The account was disabled, its processes terminated, and the relevant evidence preserved.

Further investigation should focus on determining how the account was initially compromised, whether credentials were reused elsewhere, and whether any additional persistence or privilege escalation occurred on the system.