Possible reverse shell incident with Freenlens 1.10.3

[akkie]

After upgrading freelens this morning to 1.10.3, my mac was classified as high risk because of a possible reverse shell incident.

Is there something known? Is there some code in freelens which could call this IP address? Maybe it is a false positive?

[dex4er]

Thanks for reporting this with the full alert details — the screenshot has enough
information to explain it, and it is a false positive. Nothing in Freelens opens a
reverse shell, and there is no hardcoded IP address anywhere in the codebase. Here
is what Defender for Endpoint actually saw.

The remote address is the npm registry

104.16.9.34 belongs to Cloudflare (CLOUDFLARENET, 104.16.0.0/12), and it is one
of the twelve addresses that registry.npmjs.org currently resolves to:

$ dig +short registry.npmjs.org | sort -V
104.16.0.34
104.16.1.34
104.16.2.34
104.16.3.34
104.16.4.34
104.16.5.34
104.16.6.34
104.16.7.34
104.16.8.34
104.16.9.34
104.16.10.34
104.16.11.34

Defender knows this too — registry.npmjs.org is drawn as a separate node in your
incident graph, next to the IP. It just did not connect the two in the alert title.

Freelens contacts that host on purpose. On the Welcome page it checks whether a newer
release exists, by requesting the published version of its own npm package:

• new-version-notification.injectable.tsx#L31
  — the Welcome page asks the main process for the latest version
• get-latest-version.injectable.ts#L20
  — GET https://registry.npmjs.org/@freelensapp/core/latest, 5 s timeout

The same call backs the "latest version" line in the
About dialog,
and npm is also the default registry for installing extensions. It is a plain HTTPS GET to port 443
for a public JSON document — no credentials, no payload, no inbound channel.

Why it was classified as a reverse shell

The heuristic that fired is visible in the alert body: Std out path: socket:[...]
plus T1059: Command and Scripting Interpreter / T1059.004: Unix Shell. In other
words: a shell-family process whose standard output is a socket, correlated with an
outbound connection. That pattern is the signature of a reverse shell — and it is also
an exact description of a feature Freelens inherits from Lens: shell sync. That
makes shell sync the most likely trigger, though the screenshot alone cannot prove
which child process Defender sampled (see the note below).

At every application start, on macOS and Linux, Freelens runs your login shell once to
import your real PATH and environment, so that kubectl, cloud CLI helpers and
credential plugins resolve the same way they do in your terminal
(setup-shell.injectable.ts#L21-L31,
run at every start via onLoadOfApplicationInjectionToken and logged as
Syncing shell environment / [SHELL-SYNC]). The implementation in
compute-unix-shell-environment.injectable.ts
does all of the following:

• spawns your interactive login shell (zsh -l -i) from a GUI application —
  #L89-L97
  (-i because zsh does not read its rc files in non-interactive mode, even with -l),
• passes the command over stdin rather than argv —
  #L190,
• has that shell execute the Electron binary as Node with inline code to dump
  process.env —
  #L88
  and ELECTRON_RUN_AS_NODE=1 at
  #L107,
• spawns it detached: true —
  #L119-L123,
• captures stdout/stderr through child_process.spawn pipes —
  #L137-L138
  — which libuv implements as an AF_UNIX socketpair, hence Defender reporting
  stdout as socket:[…] instead of a file or a tty.

Every one of those traits is individually on an EDR's watchlist, and the command
being fed via stdin means the argv Defender captured carries no evidence of what
was actually run. Combine that with a concurrent HTTPS connection from the same
process tree and you get precisely the alert you are looking at.

To be explicit about what is and is not established here: the identity of the remote
address, the nature of xpcproxy, and the fact that the socket on stdout is not the
socket carrying the connection are all verifiable from your screenshot plus the source.
Which specific child process Defender sampled is an inference — the alert names the
xpcproxy stub and the graph collapses the rest into "6/8 Processes", so the evidence
is consistent with shell sync but does not name it.

For what it is worth, we have not seen this alert on our own macOS machines running
1.10.3 — but to be precise about that comparison, the Microsoft Defender we run
locally is the consumer edition, which does not implement the behavioural EDR
detections that produced your alert, so it is not a like-for-like test and you should
not read it as one. What does hold generally is that a detection like this depends on
the Defender for Endpoint policy your organization applies, on cloud-delivered
protection and prevalence data, and on whether both halves of the correlation land in
the same window — the npm request only fires when the Welcome page is shown, so an
instance that opens straight into a cluster view makes no such connection at startup.
That variability is normal for a heuristic, and it is another reason to treat this as
a false positive rather than as evidence about the binary.

The two sockets in the alert are not the same socket

This is what makes it a false positive rather than a near-miss. socket:[8433422089977194109]
in the "Std out path" field is a local AF_UNIX socketpair between the Freelens
main process and its child — it has no remote address and never leaves the machine.
On macOS you can see the fd type for yourself; a child spawned by Node with piped
stdio gets Unix-domain sockets rather than FIFOs:

$ lsof -p <child pid> | awk 'NR==1 || $4 ~ /^[012][ur]?$/'
COMMAND  PID   USER   FD   TYPE             DEVICE SIZE/OFF                NODE NAME
sleep   6699 dex4er    0u  unix 0x3792a3acc4bf0743      0t0                     ->0xe40bc9f0b6ca9b25
sleep   6699 dex4er    1u  unix 0x880cfdc06f02183b      0t0                     ->0xa6e1868baad09a87
sleep   6699 dex4er    2u  unix 0x11391914af1694a7      0t0                     ->0x74e72999b9cbce98

In an actual reverse shell, the shell's stdout is the same socket as the TCP
connection to the attacker — that is the whole mechanism. Here the socket on stdout
and the connection to 104.16.9.34 are two unrelated file descriptors, in different
processes, one local and one an HTTPS request to a public registry. Defender
correlated them at the process-tree level and inferred a channel that does not exist.

About xpcproxy

xpcproxy is not a Freelens process. It is the macOS system stub that launchd uses
to bootstrap a spawned process: the new process starts out as the xpcproxy image
and only then execs its real binary. application.app.freelens.Freelens.55643129.55643896
is the launchd service label of your Freelens instance, which is xpcproxy's own
argv — which is why the "Command line" field in the alert tells you nothing about
the actual command. Defender sampled the process during that brief window, so the
alert is attributed to the stub rather than to the binary that replaced it.

Why it appeared right after the upgrade

Neither behaviour is new in 1.10.3. Shell sync dates back to the original Lens
codebase, and the npm version check has been in the Welcome page since v1.x
(November 2025). What the upgrade changed is the binary: a new build has a new
hash and no local prevalence history, so a behaviour that was previously tolerated
gets re-evaluated and alerted on. The upgrade also restarts the app, which is what
runs shell sync and the version check in the first place.

Verifying it yourself

If you want to confirm it locally rather than take my word for it:

• Freelens's own log will contain Syncing shell environment and a [SHELL-SYNC]
  result line at startup.
• A network monitor (Little Snitch, lsof -i -a -p <pid>, or Defender's own
  timeline) will show the destination as port 443 on a Cloudflare address for
  registry.npmjs.org, with no listening socket and no inbound connection.
• The full source of both code paths is linked above. registry.npmjs.org appears in
  exactly two places in runtime code: the version check, and the
  default extension-install registry
  (Preferences, "Extension Install Registry"), which is contacted only when you
  install an extension and can be pointed at your own registry.

What would let us confirm it

If you can share any of these, we can turn the inference above into a certainty:

• The process tree from the Defender timeline for that alert — specifically what the
  xpcproxy at PID 1757 execed into, and whether a zsh/bash/fish child of
  Freelens appears around 5:44:35 PM. That single fact confirms or rules out shell sync.
• Your login shell (echo $SHELL) and whether the app opened on the Welcome page or
  restored straight into a cluster view.
• Whether the Freelens log for that session contains Syncing shell environment
  followed by a [SHELL-SYNC] success or failure line.

None of this is needed to close the security question — the connection went to a public
package registry over HTTPS and there was never an inbound channel — but it would tell
us which code path to make configurable.

I would suggest reporting it to Microsoft as a false positive, and if your policy
requires it, allow-listing the Freelens bundle.

Making both of these optional is a fair request for machines under a managed EDR:
the startup version check has no opt-out today, and shell sync has no toggle at all
(only a choice of which shell to use). We will consider adding preferences for them
after the v2.0.0 release — the 1.x line is in maintenance mode, so this is not a
change we want to make there.