Is This Mac Process a Virus? How to Tell If a macOS Process Is Safe

You open Activity Monitor because your Mac feels slow, and near the top of the list is something called nsurlsessiond, or photoanalysisd, or trustd. You have never installed anything by that name. A quick search turns up forum threads with confident, contradictory answers. This guide gives you a repeatable way to decide for yourself — four checks that separate a normal macOS daemon from something that actually deserves suspicion.

Quick Answer

Most strangely named processes on a Mac are ordinary system services, but the name alone cannot tell you whether one is safe. The strongest first checks are where the executable lives and whether its code signature is valid and consistent with its claimed identity. A system-sounding process in a user-writable or temporary directory, an invalid signature, or a signer that does not match the software all warrant investigation. These are strong signals rather than proof on their own, so parent process, persistence, and behavior still matter. Activity Monitor cannot show code-signing details; ProcXray puts the signing information and full executable path alongside the running process.

Why the Name Alone Tells You Nothing

macOS runs several hundred background processes on an idle system. Most have terse, unexplained names, because they were never meant to be read by users — bird, secd, distnoted, rapportd, hidd. None of these are documented in any user-facing Apple material, which is why searching a process name so often leads to a forum thread where three people guess and one person recommends reinstalling macOS.

Worse, the name is the one attribute malware can trivially copy. A malicious binary can call itself WindowServer or mdworker and it will show up in Activity Monitor under that name. Name-based judgment is exactly backwards: it trusts the only field an attacker fully controls.

The four checks below go in order of how quickly they resolve the question.

Check 1: Where Does the Binary Live?

This one check settles the majority of cases.

macOS keeps its own executables in a small number of protected locations. macOS Catalina introduced a dedicated read-only system volume, and macOS Big Sur added the cryptographic protections of the Signed System Volume. With the normal security configuration intact, running software cannot simply add a binary to /System/. System Integrity Protection also restricts changes to other protected system locations.

Common locations for legitimate system software:

• /System/Library/... — frameworks, private frameworks, and their support binaries
• /usr/libexec/ — the majority of small background daemons
• /usr/sbin/ and /usr/bin/ — system utilities
• /sbin/ — core tools including launchd itself
• /Applications/ — apps you or the system installed; the location alone does not make an app trustworthy

Locations that warrant a closer look:

• /tmp/, /var/tmp/, /private/tmp/ — nothing legitimate should be running from here long-term
• ~/Library/ — some legitimate helpers live here, but so does most Mac adware
• /Users/Shared/ — a common staging directory for malware
• /usr/local/bin/ and /opt/homebrew/bin/ — common Homebrew locations on Intel and Apple silicon respectively; neither path proves that a binary is safe

To get a quick view of a process name and parent from its PID:

ps -o pid,ppid,user,comm -p <pid>

To inspect the command line it reports:

ps -ww -o pid,ppid,user,args -p <pid>

Treat comm and especially args as clues, not trusted provenance: a process can change the arguments that ps displays, and the output does not always reveal the actual executable path. In Activity Monitor, double-clicking a process and choosing Open Files and Ports can expose the executable among its open files, but the path is buried among unrelated entries and is not available in a dedicated column. For more ways to inspect running processes, see How to Check Running Processes on Mac.

Check 2: Who Signed It?

The path tells you where a file is. Code-signing tools can separately verify that the signed code has not been altered and display the identity recorded in its signature.

# Verify signature integrity. No output means success.
codesign --verify --strict --verbose=2 /usr/libexec/trustd

# Display signing details.
codesign -dvvv /usr/libexec/trustd

The first command performs the verification; codesign -d by itself only displays metadata. The display output varies across macOS releases and binaries, so interpret it together with the path and verification result:

• Apple system code should verify successfully and reside on a protected system path. Depending on the binary, the display may show an Apple authority chain, an Apple identifier, or platform-signing attributes. A missing TeamIdentifier is normal for many Apple system binaries.
• Authority=Developer ID Application: Some Company (AB12CD34EF) — a third-party app distributed outside the App Store, signed with a Developer ID that Apple issued and can revoke. The company name should match the app you think it is.
• Authority=Apple Mac OS Application Signing — an app installed from the Mac App Store.

Results that warrant investigation include:

• Verification fails — the signature is invalid, a sealed component changed, or the code does not satisfy its own signing requirement.
• code object is not signed at all — expected for some scripts or tools you built locally, but unusual for a persistently running downloaded app.
• Signature=adhoc outside a protected system location — normal for some locally built software, but it provides no verified developer identity. Some Apple system code also uses signatures whose display resembles ad-hoc signing, which is why path and system protection must be considered with it.

You can also ask Gatekeeper directly what it thinks of an application bundle:

spctl --assess --verbose=4 /Applications/SomeApp.app

accepted with source=Notarized Developer ID means Apple’s automated notarization service scanned that submitted build for malicious components and issued a ticket. It is a useful trust signal, not a guarantee that the app is harmless. rejected means the app does not satisfy the Gatekeeper policy currently being assessed; older software, local builds, and malicious software can all produce that result.

The gap here is that Activity Monitor exposes none of this. There is no signature column, no authority field, no notarization status. Answering “is this signed by Apple” through Apple’s own process viewer is not possible — you have to leave it and go to Terminal.

Check 3: What Launched It?

A process’s parent tells you how it came to exist, and that is often more informative than the process itself.

ps -o pid,ppid,user,args -p <pid>

If the PPID is 1, launchd is the process’s current parent. It may have launched the process as a configured job, or it may have adopted a process whose original parent exited. This does not by itself mean the process will restart after you kill it: relaunch behavior depends on settings such as KeepAlive and on-demand triggers. If you suspect persistence, inspect the jobs that could be responsible:

# Jobs that run as you
ls -la ~/Library/LaunchAgents/

# Jobs that run for all users
ls -la /Library/LaunchAgents/ /Library/LaunchDaemons/

Apple’s own jobs live in /System/Library/LaunchAgents/ and /System/Library/LaunchDaemons/, which are on the sealed system volume. The /Library/ versions without /System are third-party — that is where legitimate installers put things, and where unwanted software puts things too. A .plist here with a random-looking reverse-domain name pointing at a binary in your home folder is the classic adware pattern.

A parent that is a browser, document-viewer process, shell, or installer you recently ran is another lead worth following.

Check 4: What Is It Doing?

If the first three checks are consistent with the process’s claimed identity, immediate concern is lower, but they do not prove that its behavior is safe. Use current activity and persistence as additional context:

• Network connections. A background daemon talking continuously to an unfamiliar host is worth investigating. Many legitimate Apple daemons do talk to Apple servers — nsurlsessiond and cloudd do so constantly and normally.
• Loaded libraries. A protected system process loading a library from a user-writable directory is unusual and deserves investigation, but third-party apps and plugin hosts may load user-installed modules legitimately. See How to Check Loaded Modules and Libraries on macOS.
• Sustained resource use with no trigger. photoanalysisd pinning a core for an hour after you imported a photo library is expected. The same load on a Mac that has been idle for days is not.

Processes Most Often Mistaken for Viruses

Every process in this table is a normal part of macOS.

These locations are typical rather than permanent API contracts, and Apple can move components between macOS releases. A matching name in a user-writable directory is a strong warning sign; a different protected system path should be verified before being labeled malicious. For process-specific diagnosis, see the guides to kernel_task, WindowServer, and mds_stores.

What Actually Looks Suspicious

Signals worth investigating, roughly in order of concern:

1. A system-sounding name running from a non-system path. WindowServer in /Users/Shared/ is not WindowServer.
2. Unsigned or ad-hoc-signed, running from a system-adjacent directory. Legitimate software that ships to users is signed.
3. A signing authority that does not match the claimed identity. An app calling itself an Adobe updater signed by an unrelated developer ID.
4. Near-miss names. A trailing space, a swapped character, a doubled letter — mdworker_shared versus something a character off.
5. A launch agent in ~/Library/LaunchAgents/ pointing at a binary in a temp or download directory.
6. A process that reappears with a new PID within seconds of being killed, and that you cannot trace to an Apple-signed launch daemon.

Apple’s built-in XProtect automatically detects and blocks known malware and includes remediation technology that periodically checks for infections. A lack of alerts lowers concern about known threats but does not establish that every running process is safe. For a deeper investigation workflow, see How to Detect Suspicious Processes on macOS.

Doing All Four Checks at Once with ProcXray

The workflow above requires jumping between Activity Monitor and several Terminal commands, and repeating it for each process you want to clear. ProcXray was built to collapse that into one view.

Select any process and you get, in adjacent tabs of a single detail panel:

• Code signature and entitlements — the signing authority, team identifier, and what the process is permitted to do. This is the check Activity Monitor cannot perform at all.
• The full binary path, alongside the launch arguments and working directory from the Environment tab.
• The process tree, showing the parent that spawned it — so a daemon restarted by launchd is visible as such immediately.
• Open connections and file descriptors, for the behavioral check.
• Loaded modules, where an injected library shows up as a dylib loaded from an unexpected location.

Two features matter specifically for this task. Newly spawned processes are highlighted in green and exited ones fade to red and stay visible, so a process that respawns after being killed is obvious rather than something you have to catch by re-running a command. The regex search filters across names, PIDs, arguments, and paths at once, which makes it easier to investigate specific user-writable locations or compare a suspicious name with its executable path. Do not treat every process outside /System as third-party: many Apple processes legitimately run from /usr/libexec, /usr/sbin, /usr/bin, and /sbin.

FAQ

Is nsurlsessiond a virus?

No. nsurlsessiond is Apple’s background networking daemon, responsible for downloads and uploads that continue when an app is not in the foreground — iCloud sync, App Store updates, and any app using URLSession background transfers. It lives in /usr/libexec/ and is signed by Apple. High network or CPU activity from it usually means a large iCloud sync or a background app download is in progress.

How can I tell if a Mac process is legitimate?

Start with the executable path, then run codesign --verify --strict --verbose=2 <path> to validate its signature and codesign -dvvv <path> to inspect the recorded identity. Protected system paths, a valid signature consistent with the claimed developer, an expected parent, and explainable behavior are mutually reinforcing signals. A system-sounding name running from a user-writable or temporary directory warrants investigation, but no single check proves that a process is safe or malicious.

Why can’t Activity Monitor tell me if a process is safe?

Activity Monitor shows resource usage, not provenance. It has no column for code signature, signing authority, or notarization status, and the binary path is only reachable indirectly through the Open Files and Ports panel. Determining whether a process is legitimate requires information Activity Monitor does not expose, which is why the answer normally involves Terminal or a tool like ProcXray.

Can malware pretend to be a system process on macOS?

It can copy the name freely — that is trivial. Under the normal macOS security configuration, however, ordinary software cannot simply add a binary to the Signed System Volume or create a valid signature as Apple. The read-only system volume arrived in Catalina, with cryptographic SSV protection added in Big Sur. Path and verified code identity are therefore much stronger evidence than the displayed process name, while still forming only part of the assessment.

Should I kill a process I do not recognize?

No — not as a first step. Many unfamiliar daemons are load-bearing, and killing them ranges from pointless (launchd restarts them immediately) to disruptive (WindowServer ends your login session). Identify it first using the four checks. If it turns out to be unwanted software, removing the launch agent that starts it is the actual fix; killing the process only frees it up to come back.

Does macOS have built-in malware protection?

Yes. XProtect checks apps for known malicious content at first launch, when an app changes, and when XProtect signatures update; its remediation technology also periodically checks for infections. Gatekeeper verifies downloaded software and asks for approval when it is first opened, while notarization adds an automated Apple malware scan. Users can override some Gatekeeper decisions, and signed or notarized software is not automatically harmless. These protections are a strong baseline rather than a guarantee.

Sources and References

• Apple: Protecting against malware in macOS
• Apple: Signed system volume security
• Apple: About System Integrity Protection on your Mac
• macOS man-page mirror: codesign(1)
• macOS man-page mirror: spctl(8)

Download ProcXray → — free basic version and 14-day premium trial, macOS Sonoma+.