Posts

Maritime Malware Campaigns – Document Payloads

As part of our research into threats facing the marine and offshore sector, we recently uncovered an ongoing malware campaign.  It makes use of specific maritime industry related document lures, and attempts to evade detection by disguising command and control traffic as traffic to legitimate maritime-related businesses. From our examination of the documents being sent, we assess that it is likely this forms part of a wider malware distribution service that is available for purchase, but with purchasers providing the malware, configuration and targeting information.

This post will detail the specifics of this campaign, showing how it works and how we were able to uncover more information on the organizations it was attempting to impersonate.

Payload delivery

The malicious payloads are sent using a set of emails tailored to situations in the maritime industry where vessels send forms by email, often as Microsoft Word files. It is likely this is an attempt to take advantage of employees who are used to dealing with email attachments on a regular basis, and are hence more likely to open them. Some examples of email subjects seen are:

  • PAN – Pre Arrival Notification”: This is a form containing information on the vessel, cargo etc. sent to a port before arrival.
  • MV’GLYFADA’ PDA INQUIRY”: A PDA is a ‘pro-forma disbursement account’ – a statement sent by a ship’s agent to the owner before the ship arrives in a port. This email is asking for the attached ‘PDA quotation form’ to be completed and returned.
  • MV DA TAI V32 PDA FORMAT & AGENCY APPOINTMENT ETA 10-11JULY”: This is similar to the last, asking for a quotation for the vessel MV Da Tai arriving in Singapore.
  • MV XINDAQIANG DISCHARGING WHEAT”: In this case, the email is enquiring about port/berth restrictions, working hours, and discharging rates, with the attachment appearing to be the vessel particulars.
  • Vessel Sailing Detail : MV.E8Q MCC NANJING VOY – 926N, MV.I2F BLPL”: Here the email outlines a set of ‘feeder ship’ movements (ships transferring containers from local ports to central container terminals), with ’more details’ in the attachment.

It is worth noting that in all cases care has been taken to construct a plausible email message – for example, in the ‘Vessel Sailing Detail’ email, the three vessels listed are all container ships which could operate as feeder ships, and operate in the locality of the ports listed. Likewise, Xin Da Qiang is a bulk freighter which could be capable of carrying grain.

Each email also has a legitimate email signature which matches what would be expected from that company, although small typos have been introduced into phone numbers and email address to stop them working:

Feeder email

Document payload – understanding CVE-2017-8570

In each case the email attachment is an RTF file named with the .doc extension, which by default will open in Microsoft Word. When opened, the file simply prompts the user to enable editing to see the document, before using CVE-2017-8570 (RTF Composite Moniker vulnerability) to download and execute a payload on the machine.

Document example

CVE-2017-8570 has been covered by the original finder, but there were a set of similar OLE vulnerabilities discovered around the same time, and it is worth taking a look at how the RTF file is constructed to specifically exploit CVE-2017-8570, and what it drops onto the system.

Alongside text and images, RTF files can contain Microsoft OLE links and embedded files which are denoted by the \object tag. OLE (Object Linking and Embedding) data structures allow documents to contain objects created by a different application which retain their original format and can be edited with the toolbars and menus from the original application which created it.

The RTF files in this campaign contain two objects of interest; one a package and the other with a class of Word.Document.8.

The structure of the objects embedded in the RTF file is defined by the EmbeddedObject specification, for example the Word.Document.8 object:

01 05 00 00 OLEVersion
02 00 00 00 FormatID
09 00 00 00 ClassName length
4F 4C 45 32 OLE2Link
4C 49 6E 6B
00
00 00 00 00 Topic Name (null)
00 00 00 00 Item Name (null)
00 0A 00 00 Data Len (2560 bytes)

The next bytes are the ‘native data’ of the object, and the signature indicated they are a Microsoft Compound File Binary (CFB) file, which is a simplified file-system within a file:

D0 CF 11 E0 Compound File Header

Signature

A1 B1 1A E1
00 00 00 00 (x4) Header CLSID.
3E 00 03 00 Minor version Major version

The CFB file contains one sector, which is an OLEStream. It is here that the composite moniker that leads to remote code execution is defined:

01 00 00 02 Version

Signature

06 00 00 00 Flags
02 00 00 00 LinkUpdate (
00 00 00 00 Reserved
00 00 00 00 Reserved Moniker Stream size (0 = none)
00 00 00 00 Reserved Moniker
C0 00 00 00 Relative Moniker Stream size (192)
09 03 00 00 Packetised CLSID

00000309-0000-0000-C000-000000000046

Composite Moniker

00 00 00 00
C0 00 00 00
00 00 00 46
02 00 00 00 Number of monikers (2)
03 03 00 00 Packetised CLSID

00000303-0000-0000-C000-000000000046

File Moniker

00 00 00 00
C0 00 00 00
00 00 00 46
00 00|1A 00 Num ..\ at start of path Path Length (26)
00 00|25 54 File path

%TMP%\abctfhghghghghg.sct

4D 50 25 5C
61 62 63 74
66 68 67 68
67 68 67 68
67 68 67 2E
53 43 54 00
0E 00|AD DE endServer (14) VersionNumber (0xDEAD)
00 00 00 00 (x5) Reserved (20 bytes)
38 00 00 00 Unicode Path Size (56)
32 00 00 00 Unicode Path Bytes (50)
0F 00|05 00 usKey value
54 00 4D 00 Unicode File path

%TMP%\abctfhghghghghg.sct

70 00 25 00
5C 00 61 00
62 00 63 00
74 00 66 00
58 00 67 00
68 00 67 00
68 00 67 00
2E 00 73 00
63 00 74 00
C6 AF AB EC Packetised CLSID

ECABAFC6-7F19-11D2-978E-0000F8757E2A

‘New’ Moniker

19 7F D2 11
97 8E 00 00
F8 75 7E 2A

When the OLE object is loaded as the RTF file is opened, the composite moniker is bound. This means that IMoniker::BindToObject() is called which finds the object, puts it into the running state and provides a pointer to a specified interface.

As the moniker is a composite moniker, the two parts must first be bound before the pointer is returned to the calling application. Internally the BindToObject() method is called for the ‘New’ moniker, with an argument *pmkToLeft provided as a pointer to the file moniker. This means that before the new object is bound an object is created with a type determined by the extension of the path provided in the file moniker (.sct in this case). From the registry, it’s possible to see a .sct file (scriptletfile – text/scriptlet) corresponds to a CLSID of {06290BD2-48AA-11D2-8432-006008C3FBFC}:

Once the scriptlet file object has been created, the new moniker is bound, which results in a call to the object’s CreateInstance() method. When this is called, any code contained in the scriptlet file is run.

The scriptlet file is included in the RTF file using a Package object. This allows for an arbitrary file to be embedded into the document, and when the document is edited be written into %TEMP%. The scriptlet file is an interpreted COM component containing an XML representation of a script. In this case, it’s a lightly obfuscated Visual Basic script which will download a payload, save it to %APPDATA% and execute it:

In all samples seen, the download URL appeared to be hosted on a wide range of likely compromised infrastructure (e.g. machines exposing RDP or SSH). Interestingly, each executable was named with a date (e.g. EMEH2806.exe, CHIMA0807.exe). This matches the last-modified HTTP header when downloaded, so it appears to be used to track the date the malware was uploaded to the staging server.

Second stage

The second stage that is delivered varies depending on the theme of the campaign being carried out – for example, other campaigns using exactly the same RTF template and SCT file but with different email lures (e.g. purchase orders or draft contracts) deploy a range of different commercial RATs (AveMaria, AgentTesla, NanoCore, FormBook etc.). However, in the case of the maritime-focused campaign, every different email or sample results in a download of a variant of HawkEye Reborn v9.

HawkEye Reborn is a commodity remote access trojan which is available to purchase on a subscription model. It has been well documented by Talos and these samples are reasonably similar. The assembly is obfuscated (likely with ConfuserX) to make analysis more difficult. When run, the assembly spawns a child process which contains the main applications logic. This child process is stored in the PE resource section encrypted with a simple XOR cipher:

Because the two pseudo-random generators are always seeded with the same values (P_0=-1670293239 and P_1=625367976), we can create the same key sequence and decrypt the resource to obtain the clear-text executable.

This is also heavily obfuscated, this time with SmartAssembly, and so much so that no decompilers are able to successfully process it. Using dynamic analysis, however, it is possible to see that the hawkeye application extracts two Nirsoft utilities (WebBrowser PassView and Mail PassView) from the PE resource section and injects them into vbc.exe. This extracts saved credentials from browsers and email clients and saves them to temporary files on disk. The malware then queries the machine’s IP address using bot.whatismyipaddress.com, before returning any obtained credentials, the machine’s IP address, hostname and currently logged in user via email:

Notably, the malware uses STARTTLS to encrypt the email transmissions, and validates that the SMTP server’s TLS certificate is trusted. The destination email domain was registered to appear similar to a legitimate company (abrancon[.]com -> abracon[.]com), and this gives us a useful insight into the campaign’s infrastructure.

Infrastructure discovery

The email domains used for returning machine information and passwords is registered with Openprovider, and is using their shared mail infrastructure. Depending on the hostname provided in the SNI field of the TLS request, the mail server responds with the appropriate certificate. In this case, certificates issued by Let’s Encrypt are being used, and contain a list of SANs including domains being used to impersonate other maritime organisations.

Additionally, each domain also has an entry as a subdomain of penavicohhn[.]com (a misspelling of another large maritime organisation in China). It is unclear why this is (perhaps to help keep track?), but by pivoting on this in certificate transparency logs, examining other samples, and looking at passive DNS records, we were able to build a fuller list of impersonated companies:

Malicious domain Likely impersonated company
ctgtels.net Chittagong Telecom Services
tellaurus.net Telaurus Communications (now Globecomm Maritime)
anetts.net
nedai.net Neda Maritime Agency
abrancon.com Abracon (electronic parts supplier, antennas and RF components)
briocaensg.com
championtankers.com Champion Tankers (Norway)
cofcoainternational.com Cosco International
egasttrading.com E-Gas Trading CC (South Africa)
hakamfood.com Malaysian human rights society (Hakam)
marmedsaa.com Marmedsa shipping agency (part of Noatum)
meadwaysshipping.com Meadway Shipping
oceantrendcarrier.com Ocean Trend Carriers
omicronships.com Omicron Ship Management
penavicohhn.com Hainan Fanyu Foreign Wheel Agency Co., Ltd.
penavicot.com Penavico Shenzhen Logistics Ltd.
premiummaritime.com Premium Maritime S.A.
roxanashiping.com Roxana Shipping S.A.
seaposvcs.com Seaport Services Pvt Ltd.
sunbeamlogistic.com Sunbeam Logistics.
goshipg.com Go Shipping
gulfagancys.com Gulf Agency Services
bulkshiping.com Bulk Shipping (Pakistan)
thecencoa.com Thesarco Shipping
brise-chartering.com Briese Chartering
seacon-dz.com La SARL SEACOM
age-line.cf AGE-LINES Co. Ltd (Vietnam)
age-lines.cf AGE-LINES Co. Ltd (Vietnam)
firstcoast.cf FirstCoast Maritime Academy
gpl-sg.ml Genshipping Pacific Line
lldc.cf
nsuship.cf NS United Shipping
chunweshipping.com China Shipping
vpnet.cf Vostochny Port (vpnet.ru)
tonglishippingpte.cf Tongli Shipping
tonglishippingpet.com Tongli Shipping
arnshipping.com
safeshipg.com Safe Shipping
bestshipping-th{.tk and .cf}
clipper-group.cf Clipper Group (Denmark)
dragoncarriers.cf Dragon TS (Shanghai)
ghchemical.ml GH Chemicals
imcshipping.cf IMC Industrial
mantaship.tk Manta Shipping (Egypt)
novaa-ship.com Nova Group (Singapore)
stsall.com
sunbeamlogistic.com Sunbeam Logistics (India)
xingher-com-my.cf Xing Her International (Malaysia)

One of these domains was also a subdomain of bertlng.com, and pivoting around certificates issued to that domain gives another set of domains registered in much the same way. Again, there is a significant focus on maritime organisations, although in this campaign there also appears to be more targeting of the oil and gas sector:

Malicious domain Likely impersonated company
163-cn.(cf, gq, ga) NetEase ISP
163-com.gq NetEase ISP
bayport-eu.cf Bayport (Spain)
bestshipping.cf Best Shipping (Bermuda / Japan)
bestshipping-th.tk Best Shipping (Thailand)
brenntag-be.tk Brenntag (Belgium)
chemipakhsh-ir.cf Chemi Pakhsh (Iran)
ership-com.cf Ership Group (Spain)
fleetship-com.cf Fleet Mangement Ltd. (Hong Kong)
glweststardubai-com.tk Globelink West Star Shipping (Dubai)
goodrichsin.tk Goodrich (Singapore)
greatsourcebd.tk Great Source (Bangladesh)
gz-btb.tk
independencesxm-com.cf ISA Independence Shipping Agency (St. Martin)
leedshr-com.cf Leeds HR (Singapore)
nautilusws-com.bertlng.com Nautilus World Services (Greece)
nicesea-vn.cf Nice Sea (Vietnam)
nosm-sg.cf New Ocean Shipmanagement (Singapore)
pvi-vn.cf PetroVietnam
rahaoil.cf Raha Group (Turkey)
rotaryeng-sg.cf Rotary Engineering (Singapore)
rotarymec-my.cf Rotary Engineering (Malaysia)
sea-win-cn.tk Sea-win International Freight Forwarding (China)
simsl-com.cf Steamship Mutual
solpetroleum-com.tk Sol Petroleum (Caribbean/South America)
sttat-tn.cf STTAT Group (Tunisia)
swissmarine.cf SwissMarine (Switzerland)
tbadespachantes-ar.tk Toffoli Bassetti & Asociados Group (Argentina)
vascomaritime.tk Vasco Maritime (Singapore)
vicentin-ar.tk Vicentin SAIC (Argentina)
viconshipsg.cf Viconship (Vietnam)
vietfracht-vn.cf Vietfracht (Vietnam)
vimc-shipping.cf Vietnam Maritime Corporation (Vietnam)
www.bertlng.com Bertling Group (Germany)
wzbonai.cf Wenzhou BoNai Auto Radiator Co.,Ltd. (China)

RTF document templates?

The use of objclass PacJage to describe the package OLE object in the RTF files stood out, as in many online examples the ‘correct’ term Package is used. On pivoting on that and some other unique strings such as filenames and object dimensions it quickly became apparent that the same RTF file ‘template’ is being used to deliver many different types of trojan, and using many different document lures.

Each lure tended to cluster with a particular family of Trojan (for example, fake purchase orders with Ave Maria), but the only thing that changed in the RTF document was the second stage download URL.

It’s difficult to be certain, but this appears to be indicative of malware distribution being offered as a service, where the ‘purchaser’ provides the Trojan and email content and another party provides the delivery mechanism.

There is evidence that the RTF ‘template’ is continuing to be developed with more recent versions demonstrating additional obfuscation of the VBScript contained within the embedded .sct file (for example Base64 encoding the second stage URL). Despite this other aspects of the RTF file such as the objclass PacJage remains consistent.

IOCs

There are a large number of hashes associated with the documents and hawkeye samples, so this list is not exhaustive. Samples had generally good anti-virus detection.

“ISPS PAN.doc” b0d83bb3dc8e01765642e6510f46f0db5edcc16891786d8a0575ae858f391b3d
“Lotta Auerbach.doc” f68341864769aedfff59b50cf63fc1035669dd7b45fbeb372378d9abfa45c4b5
VESSELXPARTICULARS.doc 5a6a48549a74100fb9c9ca70fbe0cb71d9ce6faf09e8379e28f3c488080e4f37
EMEH2806.exe 3441692b35d9730791292ce06e434aa4ccf354e9f4130019cdadbb5f18dc174b
ANIBYTE06062019.exe ada205992fb9c251e606134f349e0ed64589e909d9c884ef83d0dabaff448566
CHIMA2407.exe 9a4f94fb43afa4374fbb161771280369ec577e1d76ea11e0c5a260592a2e3d2d

Malware hosting locations frequently change, and are often taken down relatively quickly. All URLs seen have been reported to/are present on the URLHaus abuse feed: https://urlhaus.abuse.ch/.

Monitoring for traffic to the mail.<domain> subdomain of the domains in the tables above will detect infected clients. This appears to be an ongoing campaign so it is expected more domains will be added.

The following yara rule will match the RTF file ‘template’ used in the campaigns seen to date with a low false-positive rate:

 

 

Using PoolTags to Fingerprint Hosts

Commonly, malware will fingerprint the host it executes on, in an attempt to discover more about its environment and act accordingly.

Part of this process is quite often dedicated to analyzing specific data in order to figure out if the malware is running inside a VM, which could just be a honeypot or an analysis environment, and also for detecting the presence of other software.  For example, malware will quite often try to find out if a system monitoring tool is running (procmon, sysmon, etc.) and which AV software is installed.

In this article, we will introduce another method of fingerprinting a host that could be potentially abused by malware.

Common ways of host fingerprinting

In this section we provide a short list of well-known ways of detecting a VM environment, and the presence of other security software, that are often applied by malware. Note that the following list is not exhaustive.

  • Process Enumeration
  • Loaded modules Enumeration
  • File Enumeration
  • Data Extracted from Windows Registry (Hard disk, BIOS etc…)
  • Loaded drivers enumeration
  • Open a handle to specific named device object
  • System Resources Enumeration (CPU cores, RAM, Screen Resolution, etc…)

The PoolTag way

If you have some experience with Windows kernel drivers development & analysis, you should be familiar with the ExAllocatePoolWithTag [1] function that is used in order to allocate memory chunks at kernel level.  The key part here is the ‘Tag’ parameter that is used in order to provide some sort of identification for a specific allocation.

If something goes wrong, for example because of a memory corruption issue, we can use the specified Tag (up to four characters) in order to associate a buffer with a code path in the kernel driver that allocated that memory chunk. This method is adequate for detecting the presence of kernel drivers, and thus software that loads modules in the kernel that could potentially circumvent the fingerprinting methods mentioned above, which rely on information that a driver could potentially alter.  In other words, it is ideal for detecting the stuff that really matters from the malware author’s point of view.

For example, security/monitoring software might try to hide its processes and files by registering callback filters at kernel level.  An analyst might try to harden their VM environment by removing artefacts from the registry and other things that malware is usually searching for.

However, what a security software vendor and/or analyst probably won’t do, is modify specific kernel drivers used by their own program and/or system/VM environment to constantly alter the Tags of their kernel pool allocations.

Getting PoolTag Information

This information can be obtained by calling the  NtQuerySystemInformation [2] function and selecting SystemPoolTagInformation (0x16) [3] for the SysteminformationClass parameter.

The aforementioned function and the associated SysteminformationClass possible values are partially documented on MSDN, but fortunately with some online research we can find some documentation done by researchers. In particular, Alex Ionescu has documented a lot of otherwise undocumented stuff about Windows internals in his NDK [3] project.

For this proof of concept, we wrote our own version of getting and parsing PoolTag information, but if you want to go the GUI way to experiment with the results, then PoolMonEx [4] is a really nice tool to play with.

For instance, the following is a screenshot of our tool’s output.  Source code below.

Which you can compare with regards to the Nbtk tagged allocations results from PoolMonEx as shown below.

QueryPoolTagInfo.cpp

Defs.h

Targetting PoolTag Information

In order to give some sense to the acquired PoolTag information, it is necessary to analyse those drivers that we are interested in. By searching for calls to ExAllocatePoolWithTag we can log specific tags used by those drivers and keep them in our list.

At this point, you should be aware that any driver can use any tag at will, and for that reason it makes sense to try to find some tags that appear to be less common and not otherwise used by standard Windows kernel drivers and/or objects.

With that being said, this method of detecting specific drivers might produce false positives if not used with extra care.

A PoolTag Example List

For the sake of demonstrating a proof of concept we have collected some PoolTag information from specific drivers.

  • VMWare (Guest OS)
    • vm3dmp.sys (Tag: VM3D)
    • vmci.sys (Tags: CTGC, CTMM, QPMM, etc…)
    • vmhgfs.sys (Tags: HGCC, HGAC, HGVS, HGCD etc…)
    • vmmemctl.sys (Tag: VMBL)
    • vsock.sys (Tags: vskg, vskd, vsks, etc…)
  • Process Explorer
    • procexp152.sys (Tags: PEOT, PrcX, etc…)
  • Process Monitor
    • procmon23.sys (Tag: Pmn)
  • Sysmon
    • sysmondrv.sys (Tags: Sys1, Sys2, Sys3, SysA, SysD, SysE, etc…)
  • Avast Internet Security
    • aswsnx.sys (Tags: ‘Snx ‘, Aw++) (We used single quotes in the first because it ends with a space character)
    • aswsp.sys (Tags: pSsA, AsDr)

Conclusion

Just like every other method, this one has its strengths and weaknesses.

This method cannot be easily circumvented, especially in 64-bit Windows where the Kernel Patch Protection (Patch Guard) does not allow us to modify kernel functions among other things, and thus directly hooking those such as NtQuerySystemInformation is not a solution anymore for security and monitoring tools.

Also, this method is not affected by drivers that attempt to hide/block access to specific processes, files, and registry keys, from userland processes.

In addition, this method could be potentially used to fingerprint the host further.

By searching for specific tags of Windows objects that are being introduced in the OS, we can determine its major version.

For example, by comparing the poolTag information (pooltag.txt) that comes with different versions of Windbg, in this case Windows 8.1 x64 and Windows 10 x64 (Build 10.0.15063), we were able to find PoolTags that are used in Windows 10 by the  netio.sys kernel driver such as Nrsd, Nrtr, Nrtw, but not in Windows 8.1

We later did a quick verification by using two VMs, and we could indeed find pool allocations with at least two of the aforementioned tags in Windows 10, while there were none of those in our Windows 8.1 VM.

That being said, it is a common and good practice for kernel driver development to use tags that make some sense based on the module that allocates them and their purpose.

On the other hand, as mentioned already, PoolTags can be used at will and for that reason we have to be careful about which ones we are targeting.

One last thing to mention is that PoolTag information changes all the time, in other words chunks of memory are constantly allocated and de-allocated, and for this reason we should keep this in mind when choosing the PoolTag to search for.

Even though this method might look more experimental than practical, in reality when malware is searching for specific monitoring and security software, PoolTag information can be very reliable.

References

  1. https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/nf-wdm-exallocatepoolwithtag
  2. https://msdn.microsoft.com/en-us/library/windows/desktop/ms724509(v=vs.85).aspx
  3. https://github.com/arizvisa/ndk
  4. http://blogs.microsoft.co.il/pavely/2016/09/14/kernel-pool-monitor-the-gui-version/

From macro to malware – a step by step analysis

We recently received an email which contained a malicious Word macro. Usually, the only thing that changes between malicious Office macros is the obfuscation that is used; e.g. changing variable names and splitting text strings. This one was different. We decided to analyse the payload and before we knew it, we were deep down the rabbit hole! Read more