The Zero2Hero malware course continues with Daniel Bunce demonstrating how to automate IOC extraction using python scripts and an example of ISFB/Ursnif malware.

For many AV companies, Threat Intelligence companies, and Blue teams in general, automation is key. When analyzing a widespread sample for the first time, such as in the case of ISFB (also known as Ursnif), it is crucial that some form of automated IOC extraction is set up. This could range from basic information such as a Bot ID and hardcoded Command and Control (C2) server addresses, all the way up to what functions are enabled or disabled. This information can be transmitted to the malware in the initial stages of infection; however, it is most commonly stored inside the binary, typically as an encrypted or compressed blob of data – this is what is referred to as the “configuration” of the malware. Immediate and successful extraction of these IOCs can assist in blacklisting, taking down the malicious C2 servers, and even emulation in order to query and download information from the live C2 servers such as webinjects or additional modules. So, with that covered, let’s take a look at a recent sample of ISFB v2 and see how we can write a fairly simple Python script to extract the configuration.

SHA 256: 2aba7530b4cfdad5bd36d94ff32a0bd93dbf8b9599e0fb00701d58a29922c75f

I won’t be analyzing the config_parser() function in-depth, so this post assumes knowledge of how the configuration is stored in the binary and any encryption/compression algorithms used to secure it.

The config_parser() function is called twice in this sample, so we can guess that there are at least 2 different blobs of data containing configuration information. We can also determine what each blob of data is, by taking a look at the hash pushed as the third argument. Looking at the image below, the variable cookie (generated during the BSS decryption function – 0x78646F86) is XOR’ed with a value before each call. The first call to config_parser() has the cookie XOR’ed with the value 0x3711A121, resulting in the value 0x4F75CEA7. This value corresponds to the name CRC_CLIENT32. This indicates that the first blob of data contains an executable, which is likely the next stage. Even though no URLs or RSA keys are stored in these blobs, the config_parser() remains the same, so once we have a working extraction script, we can extract the next stage file, and then pass that into the script to extract any additional blocks of data.

Stepping into the parsing function, we can see the cookie being XOR’ed with 0x25CC, resulting in the value 0x5DA84A4A. The last 2 bytes of this value is then moved into ECX, overwriting the first 2 bytes with zeros. This leaves the hex value 0x4A4A, which as a string is “JJ” – this is the header string of the configuration. 

The sample then begins to traverse the executable header to locate the configuration. Here, the pointer to the address of the configuration is stored inside [esi+edx+0x40]. This address points just underneath the section table, where we can see a block of data about 60 bytes in size. 

This block of data is comprised of 3 different sets of data, based on the fact the JJ header appears three times. Each set is 20 bytes in length, and follows the structure seen below.

Now we know where the lookup table is located and know the structure of it, we can begin to write our extraction script. At the moment, we need three functions; one to locate the JJ structures, one to parse the structures, and one to get the blobs of data.

Writing the locate_structs() Function

This function is responsible for locating the offset of the JJ structures inside the binary, and then calculating how many structures are actually stored, returning the positioning of the start of each structure. In order to do all this, we need to import two modules; pefile and re. Using pefile, we can traverse the executable header until we reach the offset of the JJ structures. From there, we can use re to iterate through the blob of structures to determine how many structures are inside the blob, and the starting offset of each. This is then returned back to the main() function.

With that complete, we now need to move onto parsing these structures.

Writing the parse_structs() Function

This function is fairly short and simple. First, it will split the structure blob into the individual structures, which are stored in a list. Next, the three important values (XOR key, Blob offset, Blob size) are stored inside a final list which is then returned back to the main() function.

Now that we are able to parse the structures, let’s finally look at extracting the blobs from the executable.

Writing the extract_blob() Function

Once again, this function is fairly short and simple. First, we read the data from the designated file, and then enter a loop that takes the offset and blob size from each list value, changes the endianness of the value, and uses that to locate the blob to store in a list that will be returned to main().

So, now we have successfully extracted the blobs, we need to perform decompression on them. ISFB/Ursnif uses APLib to compress the configurations, so we need to use APLib to decompress them. Rather than reinvent the wheel and write our own APLib decompression script, we can utilize some open source scripts, such as this script by Sandor Nemes. In order to decompress the blobs, we can simply pass them to the decompress function like so; decompress(blob).

We can also implement a write_to_file() function that uses the UUID module, allowing us to generate random names for each blob we extract and dump.

Wrapping Up…

And that is pretty much all! There are a few things to add, such as a function that will XOR the first 4 bytes of the executables with the XOR key in the structure in order to get the correct MZ header, or you can just add it manually. Once you have extracted the executables, you can simply replay the script against them to extract even more IOCs for further analysis. Obviously this only works on this particular version of ISFB, but that doesn’t stop you from going ahead and repurposing it for other variants such as version 3 which is more effective at storing the config.

---

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

• Zero2Hero Previous: Deep Insight Into “Fin7” Malware Chain
• macOS Catalina | The Big Upgrade, Don’t Get Caught Out!
• You Thought Ransomware Was Declining? Think Again!
• What is Deepfake? (And Should You Be Worried?)
• Checkm8: 5 Things You Should Know About the New iOS Boot ROM Exploit

Tuesday saw Apple drop the first public release of macOS Catalina, a move which has caught out a number of developers, including some offering security solutions, as well as organizations and ordinary macOS users. While SentinelOne is already Catalina-compatible (more details below), Apple’s unannounced release date has left some scrambling to catch up as macOS 10.15 introduces some major changes under the hood, undoubtedly the biggest we’ve seen in some time. Anyone considering a Catalina upgrade should be aware of how these changes could affect current enterprise workflows, whether further updates for dependency code are required and are available, and whether the new version of macOS is going to necessitate a shift to new software or working practices. In this post, we cover the major changes and challenges that Catalina brings to enterprise macOS fleets.

Does SentinelOne Work With macOS Catalina?

First things first: Yes, it does. SentinelOne macOS Agent version 3.2.1.2800 was rolled out on the same day that Apple released macOS 10.15 Catalina. This Agent is supported with Management Consoles Grand Canyon & Houston. Ideally, you should update your SentinelOne Agent version before updating to Catalina to ensure the smoothest upgrade flow.

Developers Play Catalina Catch-up

Contrary to popular (mis)belief, kexts or kernel extensions are still alive and well in Catalina, and the move to a new “kextless” future with Apple’s SystemExtensions framework remains optional at least for the time being. However, that doesn’t mean your current array of kernel extensions from other developers are necessarily going to be unproblematic during an upgrade.

New rules for kexts mean developers at a minimum have to notarize them, and users will have to restart the Mac after approving them. On top of that, developers – particularly those distributing security software – will need to update their kexts and solutions to be compatible with Catalina’s new TCC and user privacy rules, changes in partition architecture and discontinued support for 32-bit apps (see below), among other things.

Upgrading a Mac to 10.15 with incompatible kexts already installed could lead to one or more kernel panics.

The safest bet is to contact vendors to check on their Catalina support before you pull the trigger on the Catalina upgrade. If for some reason that’s not possible or you have legacy kexts installed which are out of support, the best advice is to remove those before you upgrade a test machine, then immediately test for compatibility as part of your post-install routine.

Bye Bye, 32-Bit Applications

Apple called time on 32-bit applications several releases ago, offering increasingly urgent warnings of their impending doom through High Sierra and Mojave. However, in macOS Mojave these would still run after users dismissed the one-time warning alert, but Catalina finally drops the axe on 32-bit applications.

Before upgrading, check what legacy applications you have installed. From the command line, you can output a report with:

system_profiler SPLegacySoftwareDataType

For GUI users, you can take a trip to Apple > About This Mac and click the System Report… button.

Scroll down the sidebar to “Legacy Apps” and click on it. Here you’ll see a list of all the apps that won’t run on Catalina. macOS 10.15 itself will also list any legacy apps during the upgrade process, but it’s wise to be prepared before you get that far.

VPP & Apple School/Business Manager Support

Catalina continues to allow various enterprise upgrade paths through its Mobile Device Management (MDM) framework, Device Enrollment Program (DEP) and Apple Configurator. For organizations enrolled in Apple’s Volume Purchase Program or with Apple Business Manager or Apple School Manager licensing, Catalina is supported right out of the door, saving you the bother of having to manually download, package and then install multiple instances of 10.15.

New in Catalina are Managed Apple IDs for Business, which attempt to separate the user’s work identity from their personal identity, allowing them to use separate accounts for things like iCloud Notes, iCloud Drive, Mail, Contacts and other services.

There is a plus here for user privacy, but for admins used to having total control over managed endpoints, be aware that a device with an enrollment profile and managed Apple ID means the business loses power over things like remote wipe and access to certain user data. Effectively, the device is separated in to “personal” and “managed” (i.e., business use), with a separate APFS volume for the managed accounts, apps and data.

Privacy Controls Reach New Heights

That’s not the only thing to be aware of with regards user data. The biggest change that end users are going to notice as they get to work on a newly upgraded macOS 10.15 Catalina install is Apple’s extended privacy control policies, which will manifest themselves in a number of ways.

In the earlier, macOS 10.14 Mojave, there are 12 items listed in the Privacy tab of the Security & Privacy pane in System Preferences. Catalina adds five more, with Speech Recognition, Input Monitoring, Files and Folders, Screen Recording, and Developer Tools added in the new version of macOS.

Here’s what the first three control:

Speech Recognition: Apps that have requested access to speech recognition.
Input Monitoring: Apps that have requested access to monitor input from your keyboard.
Screen Recording: Apps that have requested access to record the contents of the screen.

Importantly, the three items above can only be allowed at the specific time when applications try to touch any of these services. Although applications can be pre-denied by MDM provisioning and configuration profiles, they cannot be pre-allowed. That has important implications for your workflows since any software in the enterprise that requires these permissions must obtain user approval in the UI in order to function correctly, or indeed at all. Be aware that Catalina’s implementation of Transparency, Consent and Control is not particularly forthcoming with feedback. Applications may simply silently fail when permission is denied.

The most obvious, but certainly not only, place where privacy controls are going to cause issue is with video meeting/conferencing software like Zoom, Skype and similar. Prompts from the OS that suggest applications must be restarted after permission has been granted for certain services like Screen Recording have raised fears that clicking ‘Allow’ during a meeting might kick users out of the conference while the app re-launches. Conversely, users who inadvertently click ‘Don’t Allow’ may wonder why later attempts to use the software continue to fail.

What all this means is that with macOS Catalina, there is a greater onus on sysadmins to engage in user education to preempt these kinds of issues before they arise. Thoroughly test how the apps you rely on are going to behave and what workflow users need to follow to ensure minimal interruption to their daily activities.

The remaining two additional items are:

Files and Folders: Allow the apps in the list to access files and folders.
Developer Tools: Allow the apps in the list to run software locally that does not meet the system's security policy.

These last two can both be pre-approved. The first grants access to user files in places like Desktop, Downloads, and Documents folders. The second allows developers to run their own software that isn’t yet notarized, signed or ready to be distributed (and thus subject to macOS’s full system policy).

And New Lows…

Here’s a good example of what all this might mean in practice. Let’s take as destination a user’s machine on which File Sharing, Remote Management (which allows Screen Sharing) and Remote Login (for SSH) have been enabled.

Suppose, as admin, I choose to both Screen Share and File Share from my source machine into this user’s computer. These two different services only require the same credentials – user name and password for a registered user on the destination device – to be entered a single time per session to simultaneously enable both services, but they have confusingly different restrictions.

Trying to navigate to the destination’s Desktop folder via File Sharing in the Finder from the source indicates that the user’s Desktop folder is empty rather than inaccessible.

If I persist in trying to access any of these protected folders, the misleading Finder display is eventually replaced with a permission denied alert.

While Screen Sharing in the same session, however, I can see the Desktop folder’s contents without a problem; in fact, in this case it contains 17 items. Indeed, via Screen Sharing, I can move these items from the Desktop folder to any other folder that is accessible through File Sharing, such as the ~/Public folder. That, in a roundabout and inconvenient way, means I can get past the permission denial thrown above. Further, because I can enable other services in the Privacy pane from my Screen Sharing session, such as Full Disk Access, I can also use those to grant myself SSH access, with which I am similarly also able to work around the File Share permission denied problem.

This kind of inconsistency and complexity is unfortunate. Aside from making legitimate users jump through these hoops for no security pay-off, it raises this question: what does a legitimate user need to do to make File Sharing work properly? It seems we should go to the Files and Folders pane in System preferences and add the required process. But what process needs to be added? There’s simply no help here for those trying to figure out how to manage Apple’s user privacy controls. As it turns out, there also appears to be a bug in the UI that prevents anything at all being added to Files and Folders, so at the moment we can’t answer that question for you either.

Catalina’s Vista of Alerts: Cancel or Allow?

This expansion of user privacy controls has one very significant and obvious consequence for everyone using macOS 10.15 Catalina, graphically portrayed in this tweet by Tyler Hall.

The spectacle of numerous alerts has made some liken Apple’s investment in user privacy through consent to Microsoft’s much-maligned Windows Vista release, which had a similarly poor reputation for irritating users with an array of constant popups and dialogs, many of which seemed quite unnecessary.

Yes, your macOS users are going to be hit by a plethora of authorization requests, alerts and notifications. While Tyler Hall’s image was undoubtedly designed to illustrate the effect in dramatic fashion, there’s no doubt that Catalina’s insistence on popping alerts is going to cause a certain amount of irritation among many users after they upgrade, and who then try getting down to some work only to be interrupted multiple times. However, if the trade-off for a bit of disruption to workflows is improved security, then that’s surely not such a bad thing?

The question is whether security is improved in this way or not. Experience has taught malware authors that users are easily manipulated, a well-recognized phenomenon that led to the coining of the phrase “social engineering” and the prevalence of phishing and spearphishing attacks as the key to business compromise.

On the one hand, some will feel that these kinds of alerts and notifications help educate users about what applications are doing – or attempting to do – behind the scenes, and user education is always a net positive in terms of security.

On the other hand, the reality is that most users are simply trying to use a device to get work done. Outside of admins, IT and security folk, the overwhelming majority of users have no interest in how devices work or what applications are doing, as much as we ‘tech people’ would like it to be otherwise. What users want is to be productive, and they expect technology and policy to ensure that they are productive in a safe environment rather than harangued by lots of operating system noise.

The alert shown above illustrates the point. How informative would that really be to most users, who are unlikely to have even heard of System Events.app or understand the consequences adumbrated in the message text?

Critically, consent dialogs rely on the user making an immediate decision about security for which they are not sufficiently informed, at a time when it’s not convenient, and by an “actor” – the application that’s driving the alert and whose developer writes the alert message text – whose interests lie in the user choosing to allow.

As the user has opened the application with the intent to do something productive, their own interests lie in responding quickly and taking the path that will cause least further interruption. In that context, it seems that users are overwhelmingly likely to choose to allow the request regardless of whether that’s the most secure thing to do or not.

The urgency of time, the paucity of information and the combined interests of the user and the developer to get the app up and running conspire to make these kinds of controls a poor choice for a security mechanism. We talk a lot about “defense in depth”, but when a certain layer of that security posture relies on annoying users with numerous alerts, it could be argued that technology is failing the user. Security needs to be handled in a better way that leaves users to get on with their work and lets automated security solutions take care of the slog of deciding what’s malicious and what’s not.

Conclusion

If you are an enterprise invested in a Mac fleet, then upgrading to Catalina is a question of “when” rather than “if”. Given the massive changes presented by Catalina – from dropping support for 32-bit apps and compatibility issues with existing kernel extensions to new restrictions on critical business software like meeting apps and user consent alerts – there’s no doubt that that’s a decision not to be rushed into. Test your workflows, look at your current dependencies and roll out your upgrades with caution.

---

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

• You Thought Ransomware Was Declining? Think Again!
• What is Deepfake? (And Should You Be Worried?)
• Checkm8: 5 Things You Should Know About the New iOS Boot ROM Exploit
• Info Stealers | How Malware Hacks Private User Data
• Detecting macOS.GMERA Malware Through Behavioral Inspection
• Trickbot Update: Brief Analysis of a Recent Trickbot Payload