Posts

CVE-2020-27708: Electronic Arts (EA) Origin – Local Privilege Escalation

We recently assessed the security posture of Electronic Arts Origin Client and discovered a privilege escalation issue that would allow a low privilege attacker to elevate privileges to NT AUTHORTY\SYSTEM.  This has been recorded as CVE-2020-27708.

Origin is a digital distribution platform, by Electronic Arts, who own the brand EA Games.  They acquired the trademark Origin when it purchased Origin Systems in 1992. The platform allows some reported 39 million [1] users to download and install games by Electronic Arts.

An initial look with procmon

First, we used the free SysInternals Process Monitor tool (procmon) [2] to look for any low-hanging fruit.  Something immediately stood out; two system services looking for the directory C:\platforms, which they were not able to locate.

E:\VMShare\REVERSE_ENG\origin1.PNG

In Microsoft Windows, any user is by default able to create a directory in the root of the C drive. So, we proceeded to do just this.

We followed this with a second run of procmon.

E:\VMShare\REVERSE_ENG\origin5.PNG

As can be seen in the second procmon output, a directory listing takes place on the C:\platforms directory, which is interesting and something we made a note of.

A closer look with ProcessHacker

Our next course of action was to have a look at one of the service processes OriginWebHelperService.exe process using another free tool called ProcessHacker [3]. Something immediately stood out to us, which can be seen in the image below; OriginWebHelperService.exe is loading a DLL qwindows.dll from the directory C:\Program Files (x86)\Origin\platforms\.

Because of the similar names, C:\platforms and C:\Program Files (x86)\Origin\platforms\, we decided to copy the contents of the C:\Program Files (x86)\Origin\platforms\ directory into the C:\platforms directory.

E:\VMShare\REVERSE_ENG\ploatforms.PNG

We then ran ProcessHacker again to view the loaded modules within OriginWebHelperService.exe.

Surprisingly, this DLL was loaded directly into the OriginWebHelperService.exe process.

A bump in the road

The next step was to replace qwindows.dll with our own malicious DLL that would open a command prompt on behalf of a low level user. This is where we hit a slight bump in the road. We could see in a procmon log that our DLL was being read, however it was then closed and the original qwindows.dll was read from the Program Files path.

Using another free tool CFF Explorer [4] we took a look at qwindows.dll.

E:\VMShare\REVERSE_ENG\export.PNG

qwindows.dll has only two exported functions, qt_plugin_instance and qt_plugin_query_metadata.

E:\VMShare\REVERSE_ENG\metad.PNG

Looking at the sections within the qwindows.dll there are two that stood out to us, .qtmetad and .gfids. What if the Origin Client executables are scanning the DLL’s in the C:\platforms directory and looking for these sections before loading the DLL?

We decided to find out and proceeded to copy the data from these two sections, adding the data to our own malicious DLL into sections with identical names.

C:\Users\twilson\Documents\Nettitude\Image\qmetad.PNG

Successful privilege escalation

The result was immediate; our DLL was loaded into the OriginWebHelperService.

The OriginWebHelperService runs as Local Service, which is a low privilege account and requires some further effort in order to gain full NT AUTHORITY\SYSTEM privileges.

A recent paper by Antonio Cocomazzi [7] details several ways to break out of Local Service accounts by abusing the SeImpersonatePrivilege.  We could have attempted to use the “Chimichurri Reloaded” technique, for example [8].

However there is another service included with Origin, “Origin Client Service” which runs under the account NT AUTHORITY\SYSTEM and shares the same DLL hijacking vulnerability as the OriginWebHelperService.

At this point we changed our focus to “Origin Client Service”.

Using the sdshow command of sc.exe, the Windows Service Control tool, it was possible to view the security permissions of the Origin Client Service:

E:\VMShare\REVERSE_ENG\sdshow.PNG

The Security Descriptor Definition Language (SDDL) output from the sc sdshow command allows us to view the Security Descriptor, which suspiciously has an ACL for the well known SID string [5] “BU” is used which represents the BUILTIN\Users group.

More detail can be obtained using a PowerShell script [6]:

This allowed us to determine that any user is able to start and stop the OriginClientService.exe service process. This is an added bonus; we now don’t have to wait for reboot in order to execute our malicious payload; we can simply start the service and get as many elevated command prompts as we want:

While both the OriginWebHelperService and the OriginClientService were vulnerable to the issue, the path of least resistance was to exploit the OriginClientService gaining system privileges directly.

CVE-2020-16091 for EA Games Origin Client

We were initially issued CVE-2020-16091 by MITRE, which exclusively describes the vulnerability in this post.  Electronic Arts subsequently became a CNA and have issued a new CVE number, CVE-2020-27708, which merges a lower impact incarnation of this vulnerability with our original finding.  We have opted to lead with CVE-2020-27708, with a reference to CVE-2020-16091 noted here to avoid confusion.

Timeline

  • 27 July 2020 – Initial discovery
  • 28 July 2020 – CVE-2020-16091 issued by MITRE
  • 8 September 2020 – Electronic Arts informed of vulnerability
  • 19 September 2020 – Electronic Arts granted CNA status
  • 28 October 2020 – Electronic Arts issued CVE-2020-27708
  • 29 October 2020 – Electronic Arts released patch
  • 3 November 2020 – Nettitude release vulnerability analysis

Conclusion

It takes a relatively low effort to audit for DLL path hijacks.  Tools such as process monitor are freely available and should be leveraged as part of a products testing cycle.

Developers should also assess if they really need a service to run as NT AUTHORITY\SYSTEM. For most practical purposes, running a service under the Local Service account is just as effective and more secure; the Local Service account has various privilege restrictions, although is not immune to further privilege escalation itself [7] [8].

We identified this vulnerability in Electronic Arts Origin Windows client, version 10.5.77.42374 – 763270.  The vendor has patched this vulnerability in version 10.5.87.45080 of the client.

References

    1. Origin has 39 million users – https://venturebeat.com/2013/01/30/origin-has-39-million-users-and-4-other-surprising-numbers-about-ea/
    2. Process Monitor – https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
    3. ProcessHacker – https://processhacker.sourceforge.io/
    4. CFF Explorer – https://ntcore.com/
    5. Well known SID strings – https://docs.microsoft.com/en-us/windows/win32/secauthz/sid-strings
    6. Using PowerShell to view service ACL’s – https://rohnspowershellblog.wordpress.com/2013/03/19/viewing-service-acls/
    7. Windows Privilege Escalations: Still abusing Service Accounts to get SYSTEM privilegeshttps://www.romhack.io/dl-2020/RH2020-slides-Cocomazzi.pdf
    8. Chimichurri Reloadedhttps://itm4n.github.io/chimichurri-reloaded/

CVE-2019-16384, 85: Cyblesoft Thinfinity VirtualUI – Path Traversal, HTTP Header Injection

Nettitude discovered two vulnerabilities within Cyblesoft’s Thinfinity VirtualUI web application. The findings include path traversal and HTTP header injection, which could be leveraged to execute an XSS payload.

Thinfinity VirtualUI enables Windows-based desktop applications to function as cross-browser, cross-device web applications, which can be run on a Windows environment or be accessed remotely from a web-browser.

Path Traversal Proof of Concept – CVE-2019-16384

The path traversal vulnerability can be leveraged to perform remote data exfiltration on the Windows host.  This enables files outside of the intended web directory to be retrieved if the location is known and the application has sufficient permissions. Consequently, this compromises the confidentiality of application data.

The following proof of concept shows how common Windows configuration files were retrieved on the test host, traversing the file directories using the ../ notation. This was captured on the Cyblesoft demo site.

Vulnerable Request Including Path Traversal Payload

Vulnerable Request Including Path Traversal Payload

Local File ‘win.ini’ Displayed within Server Response

Local File ‘win.ini’ Displayed within Server Response

HTTP Header Injection Proof of Concept – CVE-2019-16385

The identified HTTP header injection vulnerability enables control over the application response and can be leveraged to perform a reflected Cross-Site Scripting attack.

The vulnerable mimetype URL parameter can be injected with an arbitrary payload, which is reflected within the Content-type header of the server response, in its entirety.

Injecting HTML encoded carriage return line feed characters %0d%0a within that vulnerable parameter results in the response being split, as a new line is inserted within the header section of the server response, whilst still returning a 200 OK response.

The ability to insert newlines and arbitrary payloads gives full control over the contents of the response and as shown below can be leveraged to perform reflected cross-site scripting. The created new lines result in the proceeding response headers being interpreted as the response body, and within this new response body, the malicious JavaScript payload is injected.

An example payload consisting of encoded CRLF characters, HTML, and JavaScript is injected to reflect a basic alert box within the client.

Vulnerable Request Including HTML Encoded CRLF Characters and XSS Payload

Vulnerable Request Including HTML Encoded CRLF Characters and XSS Payload

Server Response Showing Injected JS Payload

Server Response Showing Injected JS Payload

Versions Affected

All versions up to and including Thinfinity VirtualUI 2.5.17.2 are affected by both of the vulnerabilities disclosed.

Conclusion

These vulnerability types are common in modern web applications.  The ones presented here could have a moderate impact, and it is recommended that users of the software fix the vulnerability by applying the available patch,

Cyblesoft were quick to respond, and regular communication with the vendor enabled a patch to be released to address both of these issues before public disclosure.

Thinfinity UI Vulnerability Disclosure Timeline

  • Date of discovery: 20 August 2019
  • Vendor informed: 22 August 2019
  • Vendor patch received: 14 October 2019
  • Patch confirmed effective: 14 October 2019
  • Vendor informed about planned disclosure: 14 October 2019
  • Public Disclosure: 4 June 2020

CVE-2019-13021, 22, 23: JETSELECT Network Segregation Application

Nettitude are disclosing three vulnerabilities discovered as part of a security assessment on board a superyacht. These vulnerabilities have now had patches published by the vendor, and an appropriate time period has elapsed to allow for a patching window aboard the vessels.

JETSELECT

The JETSELECT application is supplied by JetStream, a technology company specialising in the provision of various IT services to the yacht industry. Further details on the product can be found here:

http://www.jetstream.mc/our-products/jetselect/

The JETSELECT instance tested by Nettitude was hosted on Oracle Glassfish middleware, which was vulnerable to Local File Inclusion. This vulnerability allowed Nettitude to analyse the underlying source code of JETSELECT, revealing several other vulnerabilities. The Oracle Glassfish middleware was the mechanism that allowed for the discovery of the following vulnerabilities from an unauthenticated attacker perspective.

CVE-2019-13021

During installation of the JETSELECT application, an installation script is run.  It writes a copy of the master password to a .bak file stored on the filesystem.

As can be seen in the screenshot below, the CONFSFC variable is assigned to /JetSelect/SFC/resources/sfc-general.properties.

This installation script was located in /home/bondit/jsl/3passchange.sh

At the conclusion of the script, an in-place sed command replaces all previously stored password hashes with the new passwords in the sfc-general.properties file. Additionally, the previous installation password hashes are stored in a file named sfc-general.properties.bak. The full path to this file is /JetSelect/SFC/resources/sfc-general.properties.

It is possible for any low privileged user on the system to view this directory, rendering any protections that may be provided by the MySQL database or salting to be ineffective.

Whilst this does give direct access to the password hashes, Nettitude were unable to discover the plaintext password until the discovery of CVE-2019-13022, shown below.

CVE-2019-13022

Nettitude continued to probe the application, eventually gaining access to the JAR class ENCtool.jar referred to in the installation script, which is responsible for encrypting and decrypting data.

After obtaining a copy of that file, Nettitude decompiled the application and gained access to the source code. Examination of the source code revealed that the algorithm responsible for generating secure password hashes was simply a XOR function followed by Base64 encoding the output, as shown below.

Leveraging this information, it was possible to quickly develop a tool to gain access to the original plaintext input.

Using the code above, it is possible to pass a base64 encoded string obtained from the sfc-general.properties file:

python crack.py "TVxOTkpST1k="

'Encrypted' Password: TVxOTkpST1k=

'Decrypted' Password: password

This password can be used to log into the web interface of the application as an Administrator, allowing the amendment of all network segregation rules provided by the application. Additional passwords (for example, MySQL login details) can be found by examining the other files referenced in the 3passchange.sh script mentioned previously.

Examination of an additional installation script within the BondIT home directory named runSQL.sh also revealed MySQL credentials for the root account. After obtaining access to the MySQL database as root, it was simple to obtain usernames and password hashes for all other users in the JetSelect application using the following query:

SELECT * from JSL_USER

As these passwords are ‘encrypted’ using the same manner as previously described, it is possible to gain access to all accounts in the application.

CVE-2019-13023

Nettitude also discovered that the web interface of the application stored and attempted to obscure sensitive information such as RADIUS secrets and SNMP strings. These values were stored in cleartext in a property called password within the HTML of the web page. As such, it was trivial to obtain the cleartext values of these settings, even as a lower privileged user – for example, the ETO role who is not an Administrative user and who should not have access to this information.

Nettitude did not complete a full assessment of the software as that was not the objective of the engagement; it is possible that other fields within the application suffer from the same issue.

Conclusion

This scenario also serves to highlight the risks that the Marine & Offshore sector can experience in relation to securing both the information technology (IT) and the operational technology (OT) of a vessel. Many vessels are equipped with 24/7 internet connectivity, in effect making the IT not much different to that of a conventional business.

It is critical that vessel operators adopt a cyber security strategy for both their onshore and offshore operations. This should incorporate, as a minimum, a solid patching strategy (supported by a development environment hosted onshore), vulnerability assessment and rolling penetration testing.

Additionally, this case study provides a perfect example of where the OWASP ASVS testing framework can improve assurance levels, as well as ensure that security is included in the development life-cycle of applications and services. If this application was simply tested from a black box web application perspective, two of the vulnerabilities would have gone unnoticed. By combining grey box web application penetration testing with architecture reviews, build reviews, code reviews etc, it is possible to drastically improve the security of an application as a whole.

For more information on the OWASP ASVS framework, please visit:

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

Disclosure Timeline

  • 15 May 2019 – Initial communications established with vendor.
  • 24 May 2019 – Technical details provided to allocated point of contact.
  • 28 May 2019 – Follow up email sent to ensure vendor received technical details.
  • 4 June 2019 – Vendor acknowledged receipt of technical details.
  • 18 July 2019 – Nettitude requests update.
  • 21 July 2019 – Vendor replies they have a patch nearly ready, that will be released in the coming weeks.
  • 24 July 2019 – Nettitude delay disclosure to allow further time for customers to patch their software.
  • 12 December 2019 – Nettitude give vendor of notice to publicly disclose.
  • 13 December 2019 – Vendor acknowledges.
  • 22 April 2020 – Nettitude publicly disclose vulnerabilities.

Credits

Thanks to Rob Bone (R2B2) @m0rv4i for his quick PoC to ‘decrypt’ the passwords stored in the application.

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: