4 ms·
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
by TechBro8615 3y ago
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 https://twitter.com/patrickwardle/status/1648865533041967105
[1] https://objective-see.org/products/dhs.html https://objective-see.org/products/dhs.html
- noduerme 3y agoThe 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
- TechBro8615 3y agoIf 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 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)
- noduerme 3y agoI 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 https://sveinbjorn.org/sloth