Found a backdoor on my NixOS laptop disguised as a "nix-update" service?

Help
1

Hi everyone,

It seems that I’ve found a backdoor program on my NixOS laptop:

  • ~/.local/share/nix/nix-update — a 12 MB Go binary
  • ~/.config/systemd/user/nix-update.service
  • ~/.config/systemd/user/nix-update.timer

These files are not managed by my home-manager (not symlinks).

I had deepseek do the reverse engineering, and it concludes that:

It’s a heavily customized build of ligolo-ng (reverse-tunnel / pivoting tool), with:

  • garble obfuscation (buildinfo stripped, module path mangled to github.com/kDNkzoAkg/HnDBPpdeA, hardcoded C2 domain encrypted at rest)
  • uTLS / uQUIC TLS+QUIC fingerprint mimicry (refraction-networking, gaukas/clienthellod)
  • post-quantum crypto (kyber/dilithium/mldsa via cloudflare/circl)
  • gopacket TUN, hashicorp/yamux, coder/websocket, msgpack
  • protocol features: file upload/download, remote exec (os/exec), port-forwarding (“Listener” packets) — i.e. full pivoting + RCE

C2: pytorch-models-cdn.com / 139[.]180[.]189[.]72 (Singapore Vultr). That IP has been flagged as C2 in threat intel since at least 2025-01.

  • Installed 2026-10-22 22:04–22:07, in a scripted burst (binary written over ~95s, then timer, service, chmod, daemon-reload).
  • No trace in bash history, no SSH login, no cron, no proxy logs, no auditd (not enabled). So the install was done silently by something already running on the box.
  • There’s also an older odd file ~/.sys1og.conf (content is a UUID) from 2026-07-17 that I haven’t identified yet.

So it appears to be a completely legitimate backdoor program… Has anyone seen a similar program, where might it have come from, and how can I protect my devices from it?

Thanks in advance!

2

By the way, ClamAV failed to identify it:

clamscan ~/.local/share/nix
Loading:    19s, ETA:   0s [========================>]    3.63M/3.63M sigs
Compiling:   3s, ETA:   0s [========================>]       41/41 tasks

/home/yueyinqiu/.local/share/nix/trusted-settings.json: OK
/home/yueyinqiu/.local/share/nix/nix-update: OK

----------- SCAN SUMMARY -----------
Known viruses: 3628193
Engine version: 1.5.4
Scanned directories: 1
Scanned files: 2
Infected files: 0
Data scanned: 13.12 MiB
Data read: 11.73 MiB (ratio 1.12:1)
Time: 24.354 sec (0 m 24 s)
Start Date: 2026:10:27 17:53:00
End Date:   2026:10:27 17:53:24
3

I’d be more concerned about where you got this rather than what. Do you have a lot of 3rd party flake inputs/channels/pins? Maybe NUR?

4

Throw it into a VM without internet and see where it tries to connect to!

5

Yes, the most crucial point is where it comes from. But I haven’t been able to trace it yet.

First of all, it’s a regular file, not a symbolic link to the Nix Store.

I had the agent compile a complete timeline (of course, I can’t be sure if it’s accurate; for example, the backdoor might have simply deleted and updated itself at this point):

22:04:03 binary created (birth)
22:05:38 binary finished writing (mtime — 12MB over 95s, looks like a download)
22:05:54 timer created
22:06:02 service created
22:06:43 chmod +x
22:07:25 systemd daemon-reload (user level, I don't know if it's a coincidence or actively triggered by the backdoor program; according to the logs, it was a reload requested by fwupd.service. Based on my personal judgment, it's the backdoor program deliberately used the reload of the fwupd service to hide itself.)
22:07:33 first start

However, this happened on October 22nd (all times mentioned are UTC+8, consistent with the git repository time).

I checked the Nixos records, and I didn’t perform any switch operations that day:

[yueyinqiu@erthane:~]$ nixos-rebuild list-generations | grep 10-24 -C 2
70          2026-10-27 17:46:20  26.11.20261020.02c087f  6.18.57  Unknown                 []              False
69          2026-10-25 18:11:03  26.11.20261020.02c087f  6.18.57  Unknown                 []              False
68          2026-10-24 15:04:14  26.11.20261020.02c087f  6.18.57  Unknown                 []              False
67          2026-10-24 14:19:46  26.11.20261010.6510408  6.18.55  Unknown                 []              False
66          2026-10-11 16:26:13  26.11.20261010.6510408  6.18.55  Unknown                 []              False
65          2026-10-11 16:07:55  26.11.20260919.20b1ddd  Unknown  Unknown                 []              False

The more suspicious home-manager generation has already been garbage collected. But according to my git history, I did not modify the home-manager configuration on that day (or even a few days before), so there is no reason to perform a home-manager switch or other related operations.

My configuration is located here (I apologize for not keeping a detailed Git history; Sorry if this causes problems during troubleshooting):

https://github.com/yueyinqiu/NixosErthane
https://github.com/yueyinqiu/HomeAtErthane

Based on the home-manager configuration from October 17th and the NixOS configuration from October 11th. The imported content includes:

# Not really commonly used
github:Beriholic/nix-wpsoffice-cn # I use it to import some Chinese fonts; actually, quite a few people in China use this(?)
github:denful/import-tree
github:epireyn/niri-flake # This is not sodiboo/niri-flake, because I need a newer version of Niri

# Relatively well-known
github:AshleyYakeley/NixVirt/v0.6.0
github:fufexan/nix-gaming
github:in-a-dil-emma/declarative-flatpak/latest
github:nix-community/NUR
github:notashelf/nvf

# Trusted(?)
github:NixOS/nixpkgs/nixos-unstable
github:nix-community/home-manager/master

# The following are packages I developed or participated in, and should be trustworthy (unless the packaged target itself has issues):
github:yueyinqiu/NixDaemonProxy-Nix
github:yueyinqiu/MindustryBinNix
github:yueyinqiu/SubNix
github:yueyinqiu/Snavi-Nix
github:yueyinqiu/BaidunetdiskNix
github:MihomoManager/HomeManagerMihomoManager
github:bitbloxhub/nix-airgap

So… they all seem to be safe, relatively. NURs are indeed included. However, no actual NUR packages are referenced (I used to publish some of my packages in NUR, hence the reference, but later I published them directly in separate GitHub repositories; I just haven’t removed the input).

Based on these clues, if the backdoor was indeed introduced at October 22nd, I’m more inclined to believe it entered from the outside in some way, rather than originating from my home-manager or NixOS configuration.

But it seems I don’t have a good way to trace it further… Maybe that’s why I’m posting here for help. Perhaps someone has encountered the same situation? Or, what should I do next? Enable auditd, delete the file, and see if it reappears?

6

I have run it under strace: https://termbin.com/507v

The agent has compiled the following key information:

  1. resolve pytorch-models-cdn.com (A + AAAA) — and it re-resolves on
    every attempt rather than caching the IP
  2. connect 139[.]180[.]189[.]72:443
  3. complete a TLS handshake (it uses InsecureSkipVerify, so the expired
    cert doesn’t stop it)
  4. send ~347 bytes (looks like a registration blob), receive ~928 bytes back
  5. then repeat the same cycle — exactly 3 connect attempts, ~300s apart —
    and exit(1)
7

I have enabled auditd and wait to see if it will appear again. (The original backdoor program has been archived elsewhere, if anyone needs it…)

8

I’m guessing randomly, but have you used any suspicious AI proxy service (中转站)?

9

I do use such AI proxy service… So it might return a malicious tool call during a long conversation to install it? While I trust the one I’m using, this is indeed a potential entry point…

10

The problem is, they might also buy tokens from an upstream provider which is outside of your sight. You can let your agent audit your coding harness history first. Because that sounds more like “in a scripted burst” and “install was done silently by something already running on the box”.

11

Update:

Currently, no issue with the AI proxy service has been identified. It seems that I wasn’t using the agent at the time: I was trying to package FastGithub to Nix that day. Midway through, I discovered that FastGithub modifies the git configuration, so I asked if my configuration had been modified during testing. The AI ​​replied at 16:02, and then there was no further communication until 22:39 when I asked it about the differences between the Nix package it generated and the sample I provided.

The timing of the disconnection roughly matches my behavior (I left my office after 4 PM), and the location of the disconnection also matches my memory—I confirmed it didn’t affect my Git configuration, so I stopped there for the time being and continued working at home. Of course, I can’t rule out the possibility that I misremembered (and it’s impossible for me to remember the exact time), and that the agent log might have been tampered with. Furthermore, the backdoor might not necessarily have been implanted at that time.

Further investigation revealed that it may have successfully launched the attack on the 26th. This time, it ran for over an hour (it finally stopped when I shut down the laptop), instead of failing after 10 minutes:

   Oct 26 23:39:27 erthane systemd[1698]: Started nix-auto-update.
   Oct 27 01:00:32 erthane systemd[1698]: Stopping nix-auto-update...
   Oct 27 01:00:32 erthane systemd[1698]: Stopped nix-auto-update.
   Oct 27 01:00:32 erthane systemd[1698]: nix-update.service: Consumed 2.867s CPU time over 1h 21min 4.492s wall clock time, 26.5M memory peak, 2.7M memory swap peak.

Meanwhile, there is an SSH connection from the laptop to itself (I previously used SSH to bypass the issue of sudo/podman being unavailable in FHS containers, so the authorized keys contain the device’s own key):

   Oct 26 23:40:08 erthane sshd-session[411808]: Accepted publickey for yueyinqiu from 127.0.0.1 port 59846 ssh2: ED25519 SHA256:YyBrhSq1pv7EOJY/TO7NvDHxg0ejGHN9uKyN86oxAgQ
   Oct 26 23:40:08 erthane sshd-session[411808]: pam_unix(sshd:session): session opened for user yueyinqiu(uid=1000) by (uid=0)
   Oct 26 23:40:08 erthane systemd[1]: Started Session 7 of User yueyinqiu.
   Oct 27 01:00:31 erthane systemd-logind[702]: poweroff requested from client PID 499058 ('poweroff') (unit user@1000.service)...
   Oct 27 01:00:31 erthane systemd-logind[702]: System is powering down.
   Oct 27 01:00:31 erthane sshd-session[411808]: error: mm_reap: child terminated by signal 15
   Oct 27 01:00:31 erthane sshd-session[411808]: pam_unix(sshd:session): session closed for user yueyinqiu
   Oct 27 01:00:31 erthane systemd[1]: Stopping Session 7 of User yueyinqiu...
   Oct 27 01:00:31 erthane sshd[996]: Received signal 15; terminating.
   Oct 27 01:00:31 erthane systemd[1]: sshd.service: Deactivated successfully.
   Oct 27 01:00:32 erthane systemd[1]: Stopped Session 7 of User yueyinqiu.
   Oct 27 01:00:32 erthane systemd-logind[702]: Removed session 7.
   Oct 27 01:00:35 erthane systemd[1]: sshd-unix-local.socket: Deactivated successfully.

Theoretically, it has no reason to SSH into localhost… because it already has the full access. But I didn’t either, and there’s no record in the bash history. Since the timestamps match perfectly, I believe it was indeed the backdoor software’s doing. Furthermore, according to my agent’s memory, the last atime for .sys1og.conf was also on the evening of the 26th (now untraceable because it was accessed again).

By the way, the initial run on the 22nd also took a long time and consumed a lot of memory (but no file writing or SSH activity was observed during this period):

   Oct 22 22:07:33 Started
   Oct 22 23:39:18 Consumed 58.824s CPU over 1h31m45s, 1.9G memory peak

Additionally, it has no exit record, which my agent says might mean it has been daemonized?

12

It probably won’t identify who/what/how, but i guess it wouldn’t hurt uploading the binary to https://www.virustotal.com .

Edit: Also, you probably already know this, but if you stumbled upon a backdoor then there’s no saving that installation - purge it and rotate all keys/passwords to all services.

13

Oh, I was just about to add that. Virstual Total only says:

AliCloud VirTool:Linux/Packed.Obfuscated.B

ESET-NOD32 Linux/Packed.Obfuscated.B Suspicious Application

14

Oh wait a moment. There is an update?

Ikarus PUA.Linux.Obfuscated

Microsoft Trojan:Script/Wacatac.B!ml

15

I have rotated all my keys. However, I do not plan to reinstall the system for the time being (I will use another backup device first). This is because I still do not know how it entered my device and how many other devices it infected. Please let me know if any further information is needed.

16

Is this the first attack specifically targeting nix, or perhaps it is using LLMs customise the attack?

Either way, it is a good time to mention my project - nix-housing, here is a good intro:

The idea is you have minimal tools installed on your base system, and have a house for your secure environment with minimal software, e.g. ssh and git, to sign, push, and deploy.
And then I have another environment where I do development with development tooling.
And another environment for slopware.

It would mitigate the effect of such an attack, prevent it accessing your browser secrets, and prevent it spreading to other nix members and software projects through access to your credentials.

17

Update: fwupd.service appears to be a malicious program itself, rather than a normal service exploited to launch a backdoor as I initially thought. It wasn’t included in my configuration (and shouldn’t be a user-level service). Its first activity was

Oct 22 00:40:50      earth-latitude7490 systemd[1836]: fwupd.service: Consumed 1min 30.688s CPU time over 9min 20.608s wall clock time, 3.7G memory peak.

The last startup was on October 23 at 21:53. It is currently not present on my device.

This means the implant actually landed earlier than 22nd.