According to the article these are files to look for:

~/Library/._insu (empty file used to signal the malware to delete itself)
/tmp/agent.sh (shell script executed for installation callback)
/tmp/version.json (file downloaded from from S3 to determine execution flow)
/tmp/version.plist (version.json converted into a property list)

I have to admit I find it very strange that only files in /tmp are supposed to indicate the presence of the malware - or the file that had instructed the malware to delete itself.

The files in /tmp are indicators of compromise, not the staged malware. Review the "Detection opportunities" section.

This is where Jamf Pro being able to block apps by signature, not just execution process name, would be helpful.

Obviously we can't block them by name using this...

Version 1
File name: updater.pkg (installer package for v1)
MD5: 30c9bc7d40454e501c358f77449071aa

File name: updater (bystander Mach-O Intel binary in v1 package)
MD5: c668003c9c5b1689ba47a431512b03cc

Verison 2
File name: update.pkg (installer package for v2)
MD5: fdd6fb2b1dfe07b0e57d4cbfef9c8149

tasker.app/Contents/MacOS/tasker (bystander Mach-O Intel & M1 binary in v2)
MD5: b370191228fef82635e39a137be470af

The signatures have been revoked by Apple. I'm looking for confirmation if this has been added to XProtect by Apple. I have to assume so, but want validation.

Is there any recommended method of searching for these tmp files across enrolled devices?

Try SilentKnight and/or SUS Inspector to check for XProtect status and updates.

@acornetta One way would be to create an Extension Attribute for this, but then you have to wait that it gets populated.

An extension attribute seems to be the best way to find out if any of our Macs were infected. We could also temporarily setup inventory updates to run at check-in instead of daily to help populate the Mac inventories faster. We can also change the setting for what folders are searched when inventories are ran. I did this when we deployed SentinelOne since it doesn't install into the Applications folder.

We are using this EA, courtesy of @ehemmete on Slack.

#!/bin/bash

globalFilesToLookFor=(

    "/tmp/agent.sh"

    "/tmp/version.json"

    "/tmp/version.plist"

    "/tmp/agent"

    "/tmp/verx"   

)

userFilesToLookFor=( # relative to ~/

    "Library/._insu"

    "Library/Application Support/agent_updater/agent.sh"

    "Library/Launchagents/agent.plist"

    "Library/Launchagents/init_agent.plist"

    "Library/Application Support/verx_updater/verx.sh"

    "Library/Launchagents/verx.plist"

    "Library/Launchagents/init_verx.plist"

)

result=()

filesFound=0

for globalFile in "${globalFilesToLookFor[@]}"; do

    #echo "Looking for $globalFile"

    if [ -e "$globalFile" ]; then

        filesFound=$(expr $filesFound + 1)

        result+=("$globalFile")

    fi

done

allUsers=$(dscl . list /Users UniqueID | awk '$2 >= 500 {print $1}')

for username in $allUsers; do

    homeDir=$(dscl . read /Users/"$username" NFSHomeDirectory | awk -F ": " '{print $2}')

    for userFile in "${userFilesToLookFor[@]}"; do

        #echo "Looking in $homeDir for $userFile"

        if [ -e "${homeDir}/${userFile}" ]; then

            filesFound=$(expr $filesFound + 1)

            result+=("$userFile")

        fi

    done

done

if [ $filesFound -ne 0 ]; then

    echo "<result>${result[@]}</result>"

else

    echo "<result>None</result>"

fi

Just looking to understand how this EA works. So once I create the EA? Would I create a smart group based on the criteria of this EA to place the systems in the group letting me know if its infected. Thank you in advance.

@DBIAdmin You can create an advanced search or smart group to report devices that are infected, something along the lines of EA 'is not' 'None' and 'is not' 'blank' or some other logic depending on how you configure the EA

Thanks @mark.mahabir !!! I'm going to give this a try. I was just now trying to write something.

Here are a couple other SilverSparrow directories to watch for--
/Applications/tasker.app
/private/tmp/version.plist
/User/firstlast/Library/Application Support/verx_updater

I'm trying to figure out how to craft a smart group using the results of this EA. I manually created a file called "init_verx.plist" and placed it at ~/Library/LaunchAgents. The EA detects it. What I was looking for was an integer. That's what the EA seems to use. This is what I see in my machine inventory. I assume if the other files were present, I would see those too.

Hey @howie_isaacks,

Here's the EA I'm using, partially adapted from the @ehemmete EA that @mark.mahabir posted above. My results add a "Yes: " to the list of offending files so you can configure a Smart Group like in the image I've posted below.

#!/bin/bash



# Created 20210222 by Nathan Worster

# Portions adapted from @ehemmete 

# Last modified: 20210222



###############

# Variables   #

###############



user=`ls -la /dev/console | cut -d " " -f 4`

result=()

filesFound=0

suspiciousFiles=(

    "/Applications/tasker.app"

    "/tmp/agent.sh"

    "/tmp/version.json"

    "/tmp/version.plist"

    "/tmp/agent"

    "/tmp/verx"

    "/Users/$user/Library/._insu"

    "/Users/$user/Library/Application Support/agent_updater/agent.sh"

    "/Users/$user/Library/Application Support/verx_updater/verx.sh"

    "/Users/$user/Library/Application Support/verx_updater"

    "/Users/$user/Library/Launchagents/agent.plist"

    "/Users/$user/Library/Launchagents/init_agent.plist"

    "/Users/$user/Library/Launchagents/verx.plist"

    "/Users/$user/Library/Launchagents/init_verx.plist"

)



###############

# Script      #

###############



for suspiciousFile in "${suspiciousFiles[@]}"; do

echo "Looking for $suspiciousFile"

if [ -e "$suspiciousFile" ]; then

    filesFound=$(expr $filesFound + 1)

    result+=("$suspiciousFile")

    fi

done



if [ $filesFound -ne 0 ]; then

    echo "<result>"Yes: "${result[@]}</result>"

else

    echo "<result>No</result>"

fi



exit

@ncworster Thank you! I need to learn better how to write extension attributes.

@ncworster - thx for that!

@walt Thanks... I was able to figure it out. I created a couple test files in the directory to test it and it worked like a charm.

The EA from @ncworster worked great. It picked up all of the test files that I created. I setup a smart group that sends an email when a Mac becomes a member of the group.

Thanks for all your help! Anybody with copies of the malware able to identify the process name for the SilverSparrow malware to add to the restricted software?

On a related note, once we've used an extension attribute to detect the presence of the malware, is the remediation to simply delete those files? Or is a more thorough process required? I'm sure it would be a good idea to run a deeper malware scan on any affected devices, but I'm mostly curious about removing this specific piece of malware.

So far reports show it is benign, and pretty sure Apple is going to update XProtext and MRT soon.

We're removing all the aforementioned files, but it's not actually doing anything and appears to be benign so far.

Benign or not, I consider them to be hostile if they appear on someone's Mac uninvited.

Oh, undoubtedly! We're treating this as a hostile threat.

Super helpful to borrow the work here during what have been ovtherwise busy days. The scripts here work like a charm in my testing. THANKS!! like @howie_isaacks - the machine holding my test infection file poped once the EA's loaded. In the meantime I used a couple of policies to delete the core bits of the files. Now, like @jwojda --- hoping for a process name(s) to show up in a thread somewhere vs. playing whack-a-mole on what is sure to be a moving target of file names and locations. -- on related news, this post over at Objective-See is sobering news of AntiVirus missing known malware when it's been updated to run on Arm64/M1. It made the news cycle but didn't bubble up as much as the SilverSparrow news. The upshot: 'Specifically, we highlighted a Pirrit variant (GoSearch22.app) ... And while the x86_64 and arm64 code appears logically identical (as expected), we showed that defensive security tools may struggle to detect the arm64 binary' – Here's a link to the full post