How to Setup DetectX in Jamf Pro
- Go to DetectX Swift Preferences and click the ‘Observer’ tab. Click the ‘Ignore Keywords’ checkbox (you need to be a registered or licensed user). Click the ‘Edit’ button, and add the launch label of each item you want to ignore in a comma-separated list. Click the ‘OK’ button to finish.
- DetectX itself never asks for or sees your admin password. Any requests made for permissions is done via osascript or the Finder, and they deal with the password request and carry out the requested task. Were all deliberate design choices to make DetectX as safe as possible. Unlike some other security tools, DetectX itself.
- Again, DetectX Swift will still look for the malware even if there’s no Launch Agent, but more on this in the final sections below. If configured, the malware installs the Launch Agent and, by default, points it to run a binary located at /Library/Containers/.EvilOSX.
- A quick demonstration of the main functions in DetectX Swift's Profiler.
1) Create a CustomTrigger Policy to Install DetectX Swift
1) Create a CustomTrigger Policy to Install DetectX Swift Create a new policy in your Site and name it Install – DetectX Swift. Set the only trigger to “Custom” and enter the custom trigger “installdetectx”. Set the Frequency to “Ongoing”, since we want this policy to be available whenever we need it.
Create a new policy in your Site and name it Install – DetectX Swift. Set the only trigger to “Custom” and enter the custom trigger “install_detectx”. Set the Frequency to “Ongoing”, since we want this policy to be available whenever we need it. If desired the policy can also be enabled for Self Service.
In the Packages tab, add your DetectX Swift package named like “NCSU-Campus-DetectX_Swiftxxxx.pkg” where xxxx is a version number and the license package named NCSU-Campus-DetectX_Swift_License.pkg. Do not enable the “Update Inventory” option in the Maintenance tab.
Set an appropriate Scope; make the policy available to all clients in the Site.
Save the policy.
2) Create a Policy to Run DetectX Swift Searches
Create a new policy and give it a suitable name, like “Run DetectX Search.”
Set the Trigger to “Recurring Check-in,” and the Frequency to “Once per week.” If your environment demands more frequent or less frequent scanning, adjust the frequency accordingly. I will, however, caution against an “Ongoing” frequency so as not to inflate your Jamf Pro database with excessive inventory reports.
In the Scripts tab, add the run-detectx-search.py script. No parameters are necessary. Since the script is the only action of the policy, the default priority of “After” is sufficient.
Set an appropriate Scope, Usually all computers in the site.
3) Interpreting the Extension Attribute
If DetectX finds potentially malicious files, they will be listed in the “DetectX Issues” Extension Attribute in each computers record in Jamf Pro.
The date of the last scan will be followed by either:
b) If the search completes but no issues are found, the Extension Attribute will be set to None.
c) If the search has not yet completed, or an issue occurred when attempting a search, the Extension Attribute will be blank.
A normal value for the DetectX Issue Extension Attribute in the Jamf Pro computer record looks like:
NOTE that this information will only update during the daily inventory automatically collected by Jamf Pro.
To force update use
/usr/local/bin/jamf recon
The information can also be confirmed by viewing the contents of the local file:
/Library/Application Support/JAMF/Addons/DetectX/results.json
More details on this process can be found at:
and
Deploying DetectX Swift with Munki
DetectX Swift is an alternative to MalwareBytes Anti-Malware and was more economical for our district to use. It also is faster and more what we were looking for. I highly recommend it! This is a write up based on how we are deploying it here.
First things first, if you are reading this, you will need a Management License from Sqwarq for DetectX Swift; Cost is $299 USD. Once you have this, make note of the information in the email with the account information.
We decided to deploy it to /Applications/Utilities. This makes it still easy to access but out of the standard users view. We deploy it via Munki as well. You will also need to add a post-install script to register the client. Thankfully DetectX Swift allows for re-registering with no issue, so you can 'register' it after every installation. Here is the pkginfo dict for the autopkg recipe:
If you are using MunkiReport-PHP, there is a module I created in the current WIP branch. WIP is not stable for production, but should be entering beta soon. In order to use the module you will need to create a launchDaemon targeting DetectX Swift's CLI tool to output a JSON file. There is an example in the module READMD file.
I am deploying a boot-every script with Outset that does the same thing. I packaged this up as an update_for in Munki. This will provide a dashboard that will give you in-depth look at the current status of your fleet. The client tab will show you exactly what each client shows for each infection. The command structure for this is as follows:
Detectx Swift Mac Os 10.11
This will scan (if you are running it independently you must run it as root!) all users homes and report on it's findings. It is fairly quick. If you combine all of this together you get an auto-updating anti-malware solution that reports to a dashboard for every machine you deploy it too. If there are machines supsected of having malware, we call the employee and request they do a quick restart so that the boot-every script has a chance to report, then perform a Munki update check to send the data to us. So far this has proven effective and useful here.