It could be benign behavior of a poorly implemented change-watching system. But since TextEdit is an official Mac utility (right?), that would be surprising. It could also be some other benign behavior that is triggering false positives in your detection mechanism, e.g. the shell where you're running `lsof` and the `grep` process itself, which includes a `TextEdit` parameter in its command line arguments (the call is coming from inside the house!) - make sure you're verifying that it's actually TextEdit.app that has those files open, and take note of the PID.

If it's malicious, one possibility is that a malicious payload is masquerading as TextEdit using Dylib hijacking [0]. You can scan for this by using Dylib Hijack Scanner [1], a tool developed by Patrick Wardle, who was the researcher to first publicize the Dylib hijacking technique.

Also be sure to take a look at the other products from Patrick's site, some of which will help you monitor for and diagnose this kind of potentially malicious behavior.

[0] https://twitter.com/patrickwardle/status/1648865533041967105

[1] https://objective-see.org/products/dhs.html

The Dylib scan was clean...

The PID checked out as the same that had the normal TextEdit files open (fonts, etc). The working directory was Users/[myUserName]/Library/Containers/com.apple.TextEdit/Data

If you want to keep investigating, you could use Activity Monitor, filter by PID to find the offending PID, and click "Sample Process." This will dump some debugging info, which you can search for the suspicious paths, and maybe get some semblance of an idea of what the program is doing with them.

Also, if you didn't see it yet, the TaskExplorer [0] tool from Patrick Wardle will show you which files are open by which processes, and may be a more reliable detection method than a crude `lsof | grep`.

Keep in mind that you can never prove a negative, so if you can't affirmatively prove that this behavior is benign, then you need to decide how paranoid you are about it and whether it's worth doing a factory reset and full system upgrade, which is really the only way to know "for sure" (ish) that you've cleared the system of malware. If after you do that, you find the same behavior, then it was probably benign and you just wasted a bunch of time resetting your system. :)

Personally I'd assume it's benign and caution you that it's easy to fall down rabbit holes investigating suspicious processes, only to find out you were chasing your own tail. For your sanity, I recommend you mentally prioritize proving to yourself that it's benign, rather than proving that it's malicious.

[0] https://objective-see.org/products/taskexplorer.html

P.S. FWIW, I just opened TextEdit and ran `lsof -V | grep "TextEdit" > text_edit.txt`, and `wc -l text_edit.txt` shows 73 different files, all of which are system files obviously related to running TextEdit. I didn't see it opening any of my documents. (I also never use TextEdit, and so I've never opened e.g. PDF files with it, and I also have Spotlight preferences configured to omit indexing every type of file - one hypothesis here is that TextEdit is indexing files on behalf of Spotlight)

I use a tool called Sloth[0] for showing all the open files and connections of running processes. It does pretty much the same thing. Unfortunately I didn't have the presence of mind to take a memory dump of TextEdit before I quit it while it was doing this.

I'm gonna take your advice and not freak out, and try to prove that the behavior is benign. I think I'll just set up a shell script on TextEdit to alert if it ever opens anything inside /users, and watch it for awhile.

I'm still pretty unhappy that it seemed to home in on scanning my tax returns, out of a folder with thousands of other things. The read pattern looked human-guided, like what you'd do if you were browsing around someone else's filesystem.

[0] https://sveinbjorn.org/sloth

I tried the second command. I got a load of open files, but all of them system stuff or fonts, nothing suspicious.

TextEdit does store old versions of files it is working on, as with Time Machine. I wonder if what you saw was in some way related?

After quitting and reopening, that's what I see, just fonts and system files. About 10 items total, not the thousands that were there.

The files it had open were files that would never have been opened with TextEdit... like, audio scratch files from 10 years ago in deep parts of the hierarchy (and not in Apple-designated folders like Music or Documents), my tax return PDFs (not saying this was targeted, it may have been ...)

As I look at the list I captured now, it's funny. It's not alphabetical. It skips around a lot. A few dozen folders from my MP3 collection are listed there, but not in alphabetical order although the files within them are alphabetical.

I use Arq for backups, and according to Arq's runs this morning and afternoon, none of those folders were modified or slated for backup today.

You could boot in secure mode and check those files and their backups.

That, I think, is a way to verify that this isn’t malware encrypting your files.

Booting from another disk would be even better.

This is good advice, I read this out and checked as soon as I got home. I did not boot from another disk, but a random sample of files from the LSOF list are able to open; they're not encrypted. `cat` on some of the .txt files reads out the plain text. The modification dates on the files haven't changed... most of them are years old.

I've got a script running now to watch how many files it opens in the /Users dir. Right now, 6. I use it all day every day, so I'll see if anything I do triggers it to start going nuts and reading thousands of files again...

> I did not boot from another disk, but a random sample of files from the LSOF list are able to open; they're not encrypted. `cat` on some of the .txt files reads out the plain text.

If you booted from a disk that may be infected those things don’t say much. Smart malware will silently decrypt files it encrypted on read until the moment it decides to make itself known to you.