Apple has just released an update to XProtect for all versions of macOS from El Capitan or so, bringing it to version 5273.
Apple doesn’t release information about what security issues this update might add or change. This adds Yara definitions for MACOS.DOLITTLE.CT, MACOS.SHEEPSWAP.CT and MACOS.SOMA.CT using a new format of rule, with each rule given a UUID and listing SHA256 hashes of file size.
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 Sequoia 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-5273.
If you’ve upgraded to Sequoia and are still stuck at a version number of 0 or 5272, you can either leave macOS to catch up with this in its own good time, or you can force an update by typing into Terminal sudo xprotect update
then entering your admin password.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 145. The previous version was 142.
Apple doesn’t release information about what security issues this update might add or change. There are no changes in the number or names of its scanning modules, and Bastion rules also remain unchanged.
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 has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-145.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Previous articles in this series described how macOS 14.6.1 security systems check the launch of apps when full security is in force on an Apple silicon Mac, and how those are changed by disabling SIP and Gatekeeper checks. Those have shown how checks are layered in accordance with the Security architecture of macOS, how different layers are invoked according to the status of an app (whether it’s quarantined, notarized, or has been run previously), and how extensive are the effects of disabling SIP. But no account of app security can be complete without examining how it protects against real malware, the aim of this article.
Methods
In these tests, I have again run four variants of the same 14.6.1 VM:
Full Security, with SIP and Gatekeeper/XProtect enabled;
Full Security, with Gatekeeper/XProtect disabled;
Permissive Security, with SIP disabled;
Permissive Security, with both SIP and Gatekeeper/XProtect disabled.
Samples of malicious software were obtained from the Objective-See Foundation’s collection. Three were chosen:
Atomic Stealer (AMOS, or Soma)
Genieo (InstallMac)
XCSSET
These were downloaded directly to each of the four VMs, when they were running in isolation in ViableS. Each was then unZipped and the contents moved to the Documents folder to try to ensure that their code wouldn’t be subjected to app translocation. Full log extracts were obtained from the Full Security VM for the first 5 seconds after launching Atomic Stealer and XCSSET; as the Genieo sample only installed its payload and didn’t launch its code, no log record was obtained for that. Log records weren’t obtained for the other three VMs, although the results of running the malicious payloads were observed for comparison against those of the Full Security VM.
Atomic Stealer
This was presented in a disk image that hadn’t been signed by a Developer certificate, and encouraged the user to try to bypass full Gatekeeper checks by opening the malicious payload CardGame.app using the Open command in the Finder’s contextual menu, a common strategy adopted by malware developers. This ruse was spotted early as a security exception with the code -67062, indicating that the disk image was unsigned, and that resulted in the app being translocated in its disk SecTranslocateCreateSecureDirectoryForURL: created /private/var/folders/s0/[…]/CardGame.app
This appears to be a less usual cause of translocation, although strictly within its rules.
AMFI quickly found a code signature issue, as reported by the kernel AMFI: '/private/var/folders/s0/[…]/CardGame.app/Contents/MacOS/My Go Application.app' has no CMS blob?
AMFI: '/private/var/folders/s0/[…]/CardGame.app/Contents/MacOS/My Go Application.app': Unrecoverable CT signature issue, bailing out.
AMFI: code signature validation failed.
Gatekeeper and XProtect scans followed, and the CDHashes were checked with Apple’s database over CloudKit. This discovered that one of the hashes had been revoked Notarization daemon found revoked hash: {length = 20, bytes = 0xe430ea6d59a70ac00c1b8552092f4de0bbb80232}
resulting in another security exception, this time of -66992, confirming that this code has been revoked. That check was then repeated with the same result.
Shortly after that, the XProtect scan was completed, finding a match for Atomic Stealer A GK Xprotect results: PST: (vuid: 11F66D42-5827-3465-A741-F434860C2862), (objid: 20), (team: (null)), (id: (null)), (bundle_id: (null)), XPScan: 11,-7676743164328624005,2024-08-27 07:31:10 +0000,MACOS.SOMA.A
and the decision was made to present the malware warning prompt present prompt: uid=501, conn=yes, type=Malware, op.ident=2F90B5EF-D483-43C7-BBD1-77E8EABF4D62, info.ident=8D56578B-833F-4629-86F0-4E0A8EDD7D49, info={<private>}
indicating that it’s game over for the CardGame app and its disk image.
This sample of Atomic Stealer was thus detected by two different and independent methods: its CDHash ‘notarization’ check revealing its revocation, and the XProtect scan matching it to the known signature of MACOS.SOMA.A. As the first of those is unaffected by disabling SIP or Gatekeeper, it’s not surprising that the sample was detected and blocked in each of the four VMs.
Genieo
This was presented in an Installer package as an Intel binary. This claimed to install “Apple software” and triggered a request to download and install Rosetta 2 if that wasn’t already available. The installer appeared to complete without eliciting any warnings, and it’s presumed that the malware would either have been detected later when there was an attempt to launch it, or in an XProtect Remediator scan.
All four VMs behaved identically, and there was no sign of recognition that the software installed might be malicious. This raises questions about the security inherent to Installer packages and whether there might be exploits available using Intel binaries in Rosetta 2, given that it resigns translated executable code.
XCSSET
This was presented in a bogus app named Xcode. Attempting to run that resulted in its detection, and the invitation to remove it, in this case without it being positively identified.
As this was presented as an app containing unsigned code, that came under suspicion early during its assessment, and it was translocated even though it had been moved from its original location SecTranslocateCreateSecureDirectoryForURL: created /private/var/folders/s0/[…]/Xcode.app
That appears to have occurred beyond previous rules for translocation.
Gatekeeper and XProtect scans followed, and it was confirmed that the code was unsigned Error Domain=NSOSStatusErrorDomain Code=-67062
Unsigned code in: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 81906), (team: (null)), (id: (null)), (bundle_id: (null))
CDHash checks using CloudKit didn’t find a match, and were simply reported as ticket not available: <private>
Gatekeeper’s scan reported that the app didn’t contain a bundle, but XProtect found no match with current Yara rules. The decision was made to present the malware warning prompt present prompt: uid=501, conn=yes, type=Malware, op.ident=A66F9ED6-EDE7-48E9-B1F8-74CB77C43C9E, info.ident=39D1FBB5-2620-483B-AD3C-6FC5118A406F, info={<private>}
and the attempt to launch the app was blocked.
As these traits would still be detected with SIP and Gatekeeper disabled, all four VMs blocked the code and displayed the same alert to the user.
Limitations
In reality, it’s common for attacks to consist of the initial download of a small dropper, which in turn downloads the main payload. One of the disadvantages of testing malware samples is that this presentation of the payload can’t be taken into account. Payloads are often downloaded using methods that escape quarantine. Another significant difference is that samples often lack code signatures that may be present in the originals, and may change frequently as Developer certificates are revoked and replaced.
Detection information
There appears to be almost no information on how macOS detects different groups of malicious software. Inevitably, Apple provides none at all, and few in-depth analyses of malware give any details about its presentation, in terms of any signatures used, and whether they or CDHashes have since been revoked by Apple. This is a difficult area, given that many of those who analyse and report on malware work for vendors of security products. There appears to be a valuable role for independent assessment of whether and how detection takes place in macOS, major factors in any risk assessment.
I’d like to express my gratitude to the Objective-See Foundation for collecting and making available its extensive library of malware samples, without which none of these tests would have been possible.
Apple has just released an update to XProtect for all versions of macOS from El Capitan or so, bringing it to version 5272. Apple has now released this for Sequoia betas as well, using their new update mechanism.
Apple doesn’t release information about what security issues this update might add or change. This makes a small amendment in the Yara definitions to the detection signature for MACOS.d98ded3, and adds another rule to those to detect MACOS.DOLITTLE, in MACOS.DOLITTLE.DOFSTRGT.
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-5272.
If you’re running a Sequoia beta and are still stuck at 5271, don’t worry if sudo xprotect check
doesn’t offer you the update to 5272. Ignore it and run sudo xprotect update
and with any luck it will update your Mac to 5272.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Reviewing security products intended to detect and remove malicious software is far harder than it used to be. There was a time when all you had to do was set your virtual machine to Reduced Security, disable SIP, and maybe Gatekeeper too, then strip any quarantine extended attributes from samples of recent malware. With nothing to trigger checks by macOS security, the malware was fully exposed to the security software under test, and you could assess how successful the product was at detection.
Yet in Sonoma it seems that you also need to disable AMFI (Apple Mobile File Integrity), or macOS will intervene to detect the malware before the product under test, which then won’t get a look-in.
Back in Sonoma 14.4.1 I summarised those layers of checks in this diagram.
Although it’s encouraging that malware detection is now so pervasive, this makes it almost impossible to assess the other side of an anti-malware product, how well it can remove the malicious software it discovers. The same applies to Apple’s own XProtect Remediator. Stunting and tricking macOS to the point where malware can deploy fully isn’t anywhere near as easy as it was.
You know you have failed again when macOS pops up an alert like this, telling you that it has intercepted your attempt to bypass its protection.
From a user’s point of view, this can only be good. macOS security protection is designed and applied in multiple layers so that, even if something manages to trick its way past one check, the next layer is there to stop it in its tracks.
The strangest thing about XProtect Remediator isn’t the fact that, left to its own devices, it doesn’t inform the user when it detects malware, but that it will happily remove the malware it detects and let you carry on using your Mac as if nothing had happened. If you’re as old school as me, you might wonder why you shouldn’t have to wipe your Mac completely, restore it in DFU mode if an Apple silicon model, and rebuild it from scratch. Surely the slightest suspicion of anything malicious demands such a scorched earth approach?
That too depends on what security protection your Mac has active. If that includes SIP and the SSV, then there’s no known malware that can alter anything on the SSV, and what it can do on your Data and other volumes is also limited. The days of viruses wreaking havoc throughout your entire Mac thankfully seem long since past. Viruses, of course, were designed to replicate themselves throughout a Mac’s storage, but today’s trojans and stealers are after two things, and those are your secrets and money.
But that depends on the behaviour of potential victims of malware. Like any business, those who try to profit from theft of our secrets and other malicious behaviour have to consider the size of their market of victims. For many years, this was one of the Mac’s defences against malware: why would anyone want to develop for such a small proportion of potential victims, when PCs readily provided far more? More recently, some have unfortunately recognised our potential, and now we’re suffering the consequences.
This is where standard macOS security protection comes into play. At present, the great majority of Macs running Big Sur or later have SIP enabled and their SSV fully protected. The victim market for malware requiring write access to the System volume is tiny. But what if it became more usual for Macs to be unprotected, and all that malware had to do was gain root privileges to be able to write to the System volume?
This is a phenomenon akin to vaccination and resulting herd immunity in pandemics like Covid. States and nations with low protection by vaccination and little herd immunity suffered the highest rates of infection and consequent death rates. But so few realised that exercising their personal choice to remain unvaccinated had that effect, despite the fact that humans throughout the world had eliminated the deadly disease of smallpox by building herd immunity in the late twentieth century.
Security protection in macOS works in layers. Each layer you disable opens wider the window of opportunity for attackers. The more Macs that have any given layer of protection disabled, the lower the herd immunity to attack, and the more likely that malware will try to take advantage of that.
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 142. It appears this version was first released over 12 hours ago, early in the morning GMT, but was then removed from Apple’s update servers. It has just now been made available again.
Apple doesn’t release information about what security issues this update might add or change. For the first time since its release, this update removes a scanning module, for RedPine. Bastion rules remain unchanged.
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 has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-142.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Apple has just released updates to XProtect Remediator security software (Catalina or later), bringing it to version 141, and to XProtect (for all macOS from El Capitan or so) bringing it to version 5271.
Apple doesn’t release information about what security issues these updates might add or change.
XProtect’s Yara definitions add two further signatures to its long list of those for MACOS.DOLITTLE, these being qualified as DOFNPXR and DOFDLMARM.
XProtect Remediator adds a new scanning module for Dolittle, the same codename that has just had a family of 14 detection rules added in XProtect. There are no changes to Bastion rules for the behavioural version of XProtect (Ventura and Sonoma only).
You can check whether these updates have 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 has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-141 and XProtectPlistConfigData_10_15-5271.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Apple has just released updates to XProtect Remediator security software (Catalina or later), bringing it to version 140, and to XProtect (for all macOS from El Capitan or so) bringing it to version 5270.
Apple doesn’t release information about what security issues these updates might add or change.
XProtect’s Yara definitions have a single change, adding a DOFMVAD signature to its long list of those for MACOS.DOLITTLE.
No new scanning modules are added to XProtect Remediator, and there are no changes to Bastion rules for the behavioural version of XProtect (Ventura and Sonoma only).
You can check whether these updates have 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 has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-140 and XProtectPlistConfigData_10_15-5270.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
XProCheck is one of my unique utilities, to the best of my knowledge the only app that checks whether your Mac has been running its XProtect Remediator (XPR) anti-malware scanner, and reports the results of its scans in full detail. I’m delighted to release a new version of XProCheck that improves both its checks and reports.
Apple introduced XPR two years ago, as a greatly enhanced replacement for its Malware Removal Tool, MRT, which is no longer maintained. XPR is installed on all Macs running Catalina or later, and normally performs two sets of scans, one as the user and the other as root, every 24 hours or so. It currently contains scanning modules for 22 different types of malware, and one to cover those previously included in MRT’s checks. Its scans will not only detect known malware, but will also try to remove (‘remediate’) those that it does detect.
Strangely, XPR doesn’t report detections or remediations to the user, but can report them to third-party security software using Endpoint Protection (Ventura and later). As far as I’m aware, though, few if any security products make use of that, leaving XProCheck as the only way to monitor XProtect Remediator scans and reports.
XProCheck version 1.6 brings one major improvement, in changing the method used to check log entries for XPR’s reports. Previous versions have used the log show command, but this new version now reads the log directly using the OSLog API. Although this does have a small memory leak that would only be significant if you were to run dozens of checks in succession, it brings considerable improvements in speed, particularly when checking scans over longer periods, and on Apple silicon Macs.
This version of XProCheck typically takes less than 60 MB of memory before running any checks, rising to less than 70 MB after it has completed its first check. That may rise by less than 1 MB with each subsequent check made before quitting the app, so is almost unnoticeable.
There are two more cosmetic improvements: XProCheck reports now also give the time of its checks in local time as well as GMT/UTC, and the width of the scanner name field is a little greater, to better accommodate CardboardCutout.
XProCheck version 1.6 runs on all Intel and Apple silicon Macs in all versions of macOS from Catalina to Sequoia betas, and is available from here: xprocheck16-1
from Downloads above, from its Product Page, and through its auto-update mechanism.
The Macintosh was intended to be different in many ways. One of them was its file system, which was designed for each file to consist of two forks, one a regular data fork as in normal file systems, the other a structured database of resources, the resource fork.
Resources came to be used to store a lot of standard structured data, such as the specifications for and contents of alerts and dialogs, menus, collections of text strings, keyboard definitions and layouts, icons, windows, fonts, and chunks of code to be used by apps. You could extend the types of resource supported by means of a template, itself stored as a resource, so developers could define new resource types appropriate to their own apps.
Apple’s engineers developed a resource editor that quickly became one of the best-known apps on the Mac: ResEdit, last seen in version 2.1.3 way back in 1994. This was the power user’s quintessential tool: if you didn’t like a particular dialog in an app, ResEdit could be used to change it; if you wanted to create your own custom keyboard layout, it was the first choice for that too. If you were wicked enough to want to mess someone’s Mac up, you could go into their system files and change things around when they were out at lunch. Not that anyone ever did that, of course.
Each resource type had a four-character name, such as ALRT for an alert definition, CODE for executable code, DLOG for dialogs, KCHR for keyboard layouts, MENU for menus, STR for text strings, and so on.
You could have many different KCHR resources, each numbered, so that changing your keyboard layout was a matter of switching from KCHR number 2, the standard British layout, to number 26 for Dutch, for example. Adding your own custom keyboard layout was then merely a matter of defining a new KCHR resource with a unique ID number, here 128, and editing it to map the keys how you wanted.
Many resource types had custom editors: that for KCHR has a simple keyboard layout and tabular form. The highlighted (black) keys indicate that the Euro character € being shown would be generated by holding the Opt (Alt) modifier key and pressing the 2 key on the top row of the main keyboard, but not the 2 on the numeric keypad.
Customising the icon displayed for QuarkXPress was another fun job for ResEdit.
In those days, it was ResEdit that displayed the Get Info dialog for folders and files, where the sizes of resource and data forks were revealed. Note the vital Type and Creator fields shown: those used four characters that determined the icon to be used for documents, and which app would open them when double-clicked. They were used to build the Desktop Databases, mapping files to their icons and apps.
Resource forks and the thinking behind them are ingenious and empowering, but open up many security issues. In the days when there was Classic Mac OS malware, it often came in resource forks, and took advantage of their features. Although it was possible to lock and protect individual resources, armed with a copy of ResEdit you could soon change that, and almost anything else that you wished to, just as malware could and did.
This is demonstrated in the names seen in this malware library: WDEF preyed on windows resources, MDEF on those for menus, and several of these malicious files are shown with the icon for ResEdit’s resource files.
With Mac OS X, resource forks went into hiding, soon becoming extended attributes. App resources were split out into bundles, folders containing standard structures of files and more folders. Within those, the data structures that would have gone into resources are now folders full of files with standard data forks. In many cases, structured data are set out in XML, which is far less efficient than those old resources, and less suitable for power users to tamper with.
Instead of the limitless customisations to Mac OS, apps, and almost everything on your Mac, accomplished using ResEdit, apps are now locked down by their signatures, and can’t be tampered with any more. While they lasted, resources and ResEdit were exciting and satisfying, if horribly insecure.
For the first three years after the release of the Mac, it’s believed to have remained blissfully free of viruses and other unwanted and malicious software, which was only just starting to plague other personal computers.
Then came the first variant of the nVIR virus in 1987, and the following year a spate of malware in HyperCard stacks. Those were encouraged by the app’s rapid popularity, and exploited its built-in scripting language HyperTalk. John Norstad of Northwestern University responded by releasing his popular anti-virus app Disinfectant in 1989, and others followed in his wake.
Symantec Antivirus for Macintosh (SAM), renamed Norton AntiVirus (NAV) in 1998, was launched in 1989, two months after Disinfectant. McAfee later based its commercial VirusScan on Disinfectant.
During the 1990s viruses became more widespread and malicious, and some exploited features such as CD AutoPlay, widely used to run QuickTime rich media from optical disk. Apple’s new accessible scripting language AppleScript soon fell victim to a whole range of nasties, which continues to this day. In 1997, it was estimated that there were at least 35 Mac-specific viruses, together with numerous malicious macros for Microsoft Word and Excel that caused mayhem across platforms.
Here’s my small collection of samples that I used when evaluating and reviewing anti-virus products at the time. Many of these were INITs that loaded at startup, and several could prove very damaging. There were several unfortunate accidents where Mac malware was distributed by commercial sources, including one provided in the cover floppy disk of a reputable Mac design and publishing magazine.
John Norstad’s Disinfectant finally bowed out on 6 May 1998 after nearly a decade of service to the community, but there were still free tools including Agax, with its modular design, shown above.
By the end of that decade there were six commercial anti-virus products for Macs, of which the most popular were Norton/Symantec Antivirus for Macintosh, and Virex for Macintosh from Datawatch Corporation. In addition to those, two British developers offered products, Dr. Solomon’s AntiVirus ToolKit for Macintosh and Sophos, and there was one from France.
Intego, then based in Paris, first released its anti-virus Rival in 1997, initially only in French. Then in October 2000, it released the first version of VirusBarrier for Mac OS 8 and 9.
Throughout this period, Classic Mac OS retained its reputation as being largely untroubled by malicious software, despite reality. Protection provided by Mac OS seemed rudimentary if not lacking altogether. This didn’t change with the introduction of Mac OS X, at least not until Renepo/Opener, a widely publicised Trojan, appeared in 2004 and Apple was forced to add protection in Mac OS X 10.4 Tiger.
Fortunately, by that time commercial developers were supporting Mac OS X, and Tomasz Kojm’s freeware ClamAV, first released in 2002, had been ported from Unix as ClamXav.
Hot on the heels of the slightly earlier update to XProtect, Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 139.
Apple doesn’t release information about what security issues this update might add or change. There are no new scanning modules, and Bastion rules remain unchanged.
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 has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-139.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Apple has just released an update to XProtect for all versions of macOS from El Capitan or so, bringing it to version 5269.
Apple doesn’t release information about what security issues this update might add or change. This adds a whole new family of 11 rules to detect MACOS.DOLITTLE, including individual rules D2MPLN, EXTINST, AGNSYM, DYINSTXR, AGNXR, DOFSRP, DOFSDCRYP, DOFCONSH, DOFDLM, DOFINLXR and DOFDECS. Several of these are so large that the Yara file has more than doubled in size from 6,250 to over 13,200 lines.
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-5269.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Login
