hoakley February 12, 2024 Macs, Technology, Updates

Apple has just released an update to XProtect

Apple has just released an update to XProtect for all versions of macOS from El Capitan or so, bringing it to version 2185.

Apple doesn’t release information about what security issues this update might add or change. XProtect’s Yara definitions include further changes to the rule for MACOS.SOMA.E, a variant of Amos Atomic Stealer, and that for MACOS.CRAPYRATOR.A2, also known as BkDr.Activator.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-2185.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

I maintain lists of the current versions of security data files for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.

18Comments

Add yours

1

Kevorg on February 13, 2024 at 12:33 pm
Reply

SilentKnight 2 shows that XProtect disabled. What to do?

LikeLiked by 1 person
- 2
  
  hoakley on February 13, 2024 at 12:40 pm
  Reply
  
  To quote from my earlier article here:
  When Gatekeeper and XProtect are enabled, security checks are made on all executable code and apps when they’re run, to ensure they don’t contain known malware. You shouldn’t need to disable that, but if you do and forget to turn it back on, enter the command
  sudo spctl –global-enable
  which requires you to authenticate using your admin password. Be careful with that command: the hyphens before global-enable aren’t long dashes, but two separate hyphens. That doesn’t need to be done in Recovery, and should have immediate effect.
  Howard.
  
  LikeLike
  - 3
    
    Kevorg on February 13, 2024 at 12:48 pm
    Reply
    
    This is the message I get after the password:
    
    spctl: invalid option — g
    System Policy Basic Usage:
    spctl –assess [–type type] [-v] path … # assessment
    spctl –add [–type type] [–path|–requirement|–anchor|–hash] spec … # add rule(s)
    spctl [–enable|–disable|–remove] [–type type] [–path|–requirement|–anchor|–hash|–rule] spec # change rule(s)
    spctl –status | –global-enable | –global-disable # system global switch
    
    Developer Mode Usage:
    spctl developer-mode
    enable-terminal
    Add Terminal as a developer tool.
    Kernel Extension User Consent Usage:
    spctl kext-consent ** Modifications only available in Recovery OS **
    status
    Print whether kernel extension user consent is enabled or disabled.
    enable
    Enable requiring user consent for kernel extensions.
    disable
    Disable requiring user consent for kernel extensions.
    add
    Insert a new Team Identifier into the list allowed to load kernel extensions without user consent.
    list
    Print the list of Team Identifiers allowed to load without user consent.
    remove
    Remove a Team Identifier from the list allowed to load kernel extensions without user consent.
    
    LikeLiked by 1 person
    - 4
      
      hoakley on February 13, 2024 at 12:51 pm
      
      That’s because you entered the command incorrectly. As I wrote just now: Be careful with that command: the hyphens before global-enable aren’t long dashes, but two separate hyphens. To spell it out, that options should read
      hyphen hyphen global
      with no space between those hyphens or the word global.
      Howard.
      
      LikeLike
5

Kevorg on February 13, 2024 at 1:06 pm
Reply

Great, thank you, Howard!

LikeLiked by 1 person
6

Adrian B on February 14, 2024 at 10:37 am
Reply

I’m not sure if anyone else is seeing it but since the update I’m seeing large memory allocation while the scan runs, and then I’m left with a large amount of swap allocated (well, 7GB, massive for this machine!). I don’t recall ever seeing this prior to this update. At one point XProtectRemediatorSheepSwap had 11.19GB of memory allocated and 10.96GB of VM compressed (I presume the former includes the latter). Memory allocation was increasing at quite a rate. It did end eventually (yesterday I ended up rebooting the Mac mid-run), at which point the memory returned to normal (apart from the huge swap allocation), but while it was running it was definitely causing problems doing useful work. (Machine has 32GB of RAM)

LikeLiked by 1 person
- 7
  
  hoakley on February 14, 2024 at 11:02 am
  Reply
  
  Now you’re baffling me!
  Although there’s nothing to stop XProtect Remediator from using the Yara definitions provided in XProtect, I don’t know whether it does, as XPR works differently.
  This update is for XProtect, and doesn’t change XProtect Remediator as such. I don’t understand why you’re seeing changed behaviour in XPR when it hasn’t been updated.
  Are there any clues from its log reports (e.g. in XProCheck)?
  Howard.
  
  LikeLike
  - 8
    
    Adrian B on February 14, 2024 at 11:34 am
    Reply
    
    Ah, sorry, I should have guessed XProtect Remediator wasn’t necessarily included in the XProtect update.
    I’d checked the logs (using Consolation) and didn’t see anything obvious, but I’d forgotten about XProCheck and just looked — all fine. I used XProCheck to run the scan again and watched — and the memory usage was fine. So whatever tripped it up last night and this morning has resolved itself by the look of things.
    (I do find it odd that MRTv3 returns a status message of ‘success’ while the rest of the modules all return ‘NoThreatDetected’ 🙂 )
    Thanks for the suggestions (and the tools!). I’m going to keep an eye on it, but I wonder if there was some file it was having problems with and it’s now marked it as OK (struggling to think what else would cause this behaviour).
    
    LikeLiked by 1 person
    - 9
      
      hoakley on February 14, 2024 at 1:05 pm
      
      I’m delighted it all seems OK now. Maybe it was just another of those macOS mysteries? Or perhaps the system decided it was time to check something vast like Xcode.
      Howard.
      
      LikeLike
    - 10
      
      N. Hughes on February 29, 2024 at 4:05 pm
      
      It’s not just you. I’m typing this on a Mac mini that has just rebooted itself again after XProtectRemediatorSheepSwap brought it to its knees (6.4GB memory usage on a machine with 4GB RAM). There are several reports on Apple’s support forums and elsewhere about the same thing, all starting in the last couple of weeks.
      
      LikeLiked by 1 person
    - 11
      
      hoakley on February 29, 2024 at 4:07 pm
      
      Have you contacted Apple Support?
      Howard
      
      LikeLike
    - 12
      
      N. Hughes on February 29, 2024 at 4:24 pm
      
      So far I’ve sent the crash reports and posted on the support forums. I’m on Monterey but it seems to affect various MacOS versions. Nothing new (other than the MacOS security update) has been installed on this computer lately, but I’m going to create a new user and run that for a while to see if the same thing happens.
      
      LikeLiked by 1 person
    - 13
      
      hoakley on February 29, 2024 at 7:55 pm
      
      What do you see in XProCheck in the way of reports from XPR? Have you looked in the log to see what entries there were during that period?
      Howard.
      
      LikeLike
    - 14
      
      N. Hughes on February 29, 2024 at 10:30 pm
      
      The log says XProtect ran at 8:02 and then 3 more times between 20:01 and 21:23. So I’m starting to doubt my own sanity (or eyesight) because I thought I saw SheepSwap hogging RAM around 15:00 before the Mac mini rebooted itself.
      
      SheepSwap also took 4+ GB RAM twice this evening around that 20:01 window, but I see nothing unusual in XProCheck; everything is NoThreatDetected and taking fractions of a second. The log goes back about 3.5 days max so I don’t have anything to look at for the previous cases, but I’ll keep an eye on this.
      
      LikeLiked by 1 person
    - 15
      
      hoakley on February 29, 2024 at 10:32 pm
      
      Thank you. It’s all rather weird, isn’t it?
      Howard.
      
      LikeLike
16

dlesuisse on February 15, 2024 at 9:36 am
Reply

Since I updated to Sonoma 14.4, I receive an error message from Silentknight :
❌ KEXT 19.4.0 should be 19.0.0.
I don’t understand what it really means. Is it important? Should I be worried? Thanks in advance for your help!

LikeLiked by 1 person
- 17
  
  hoakley on February 15, 2024 at 9:41 am
  Reply
  
  That’s because you’re running a beta-release of 14.4, which hasn’t yet become a final release. It would appear that the update to 14.4 will bring a new version of that component. That won’t be reflected in SK’s database until it’s on general release.
  Howard.
  
  LikeLiked by 1 person
  - 18
    
    dlesuisse on February 15, 2024 at 9:48 am
    Reply
    
    Yes, I thought it was related to the beta. Thank you very much for your kind answer! Have a nice day and all the best! Dominique
    
    LikeLiked by 1 person

Share this:

Related