Pierluigi Paganini June 06, 2019

Security expert Marco Ramilli has analyzed the recently leaked APT34 hacking tool tracked as Jason – Exchange Mail BF.

Today I want to share a quick analysis on a new leaked APT34 Tool in order to track similarities between APT34 public available toolsets. This time is the APT34 Jason – Exchange Mail BF project to be leaked by Lab Dookhtegan on June 3 2019.

Context

According to FireEye, APT34 has been active since 2014. APT 34, also referred to as “OilRig” or Helix Kitten, has been known to target regional corporations and industries. Although there was information about APT34 prior to 2019, a series of leaks on the website Telegram by an individual named “Lab Dookhtegan”, including Jason project, exposed many names and activities of the organization.

“APT34 conducts cyber espionage on behalf of Iran. Iran seeks to diminish the capabilities of other regional powers to create leverage and better establish itself. This strategy is especially important against nations it sees as a threat to its regional power such as Saudi Arabia and the United Arab Emirates.”

Michael Lortz

Analysis

Jason is a graphic tool implemented to perform Microsoft exchange account brute-force in order to “harvest” the highest possible emails and accounts information. Distributed in a ZIP container (a copy is available here) the interface is quite intuitive: the Microsoft exchange address and its version shall be provided (even if in the code a DNS-domain discovery mode function is available). Three brute-force methods could be selected: EWS (Exchange Web Service), OAB (Offline Address Book) or both (All). Username and password list can be selected (included in the distributed ZIP file) and threads number should be provided in order to optimize the attack balance.

Deflating the ZIP container three artifacts are facing out. Jason.exe representing the graphic user interface and the main visible tool. Microsoft.Exchange.WebService.dll which includes the real functionalities used by Jason.exe, it’s a Microsoft developed library, PassSamplewhich includes some patterns implementation of possible Passwords (ie.[User@first]@@[user@first]123) and a folder named PasswordPatterswhich includes building blocks for password guessing. For example it wraps up a file called Year.txt including numbers from 1900 to 2020, a file called numspecial.txt including special numbers patterns and special chars patterns, a file called num4.txt including numbers from 0 to 999 and from 0002 (why not 0001 or 0000?) to 9998 (why not 9999?) and finally a file called num4special.txt including special number patters like: 1234,7890,0707, and so on and so forth.

Digging a little bit into the two Microsoft artifacts we might find out that both of them ( Jason.exe and Microsoft.Exchange.WebService.dll) have been written using .NET framework. The used .dll provides a managed interface for developing .NET client applications that use EWS. By using the EWS Managed API, the developer can access almost all the information stored in an Office 365, Exchange Online, or Exchange Server mailbox. The attacker used an old version of Microsoft.Exchange.WebService.dll tagged as 15.0.0.0 which according to Microsoft documentation dates back to 2012.

The last available Microsoft.Exchange.WebService.dll dates back to 2015, as shown in the following image, which might suggest a Jason dating period, even if it’s not an irrefutable evidence.

Analyzing the reversed byte-code a real eye catcher (at least in my persona point of view) is in the “exception securities” that have been placed. In other words, the developer used many checks such as: variable checks, Nullbytes avoidance, objects indexes and object key checks in order to reduce the probability of not managed software exceptions. These “exception protections” are usually adopted in two main scenarios: (i) the end-user is not a super “techy” guy, so he might end-up with some unexpected conditions or (ii) the attacker is a professional developer who is trained to write product oriented code and not simple working software (which is what attackers usually do). The following images show a couple of code snippets in where the developer decided to protect codes from unexpected user behavior.

Comparing the code style with my previous analyses on APT34 (OilRig) which you might find here and here, we might observe a similar code protection. Even if the code language is different the similarity in the basic exception prevention from Jason and -for example- the “ICAP.py script injection” function is very close. Another weak similarity is in the logging style. Jason and -for example- Glimpse project have a similar file logging function which includes string concatenation using special operators (no “flying casting” or “safe conversions”, ie: “%s”) and one line file logging into function focal points.

I am aware that these are weak similarities and there is no additional evidence or ties with previous leaked APT34 except for the trusted source (Lab Dookhtegan), so I am not giving any personal attribution since it gets very hard to attribute Jason directly to APT34 for what is known.

On the other hand Jason project doesn’t share the main source code language with previous APT34 analyses, it doesn’t include DNS tricks and or DNS usage evidences, it doesn’t include distinguishing patterns or language mistakes, it have been recompiled on January 2019 but using older technology. As already discussed it shares just few code style similarities with Glimpse and WebMask.

Additional technical details, including Yara Rules and IoCs, are reported in the original analysis published by Marco Ramilli on his blog:

https://marcoramilli.com/2019/06/06/apt34-jason-project/

About the author: Marco Ramilli, Founder of Yoroi

I am a computer security scientist with an intensive hacking background. I do have a MD in computer engineering and a PhD on computer security from University of Bologna. During my PhD program I worked for US Government (@ National Institute of Standards and Technology, Security Division) where I did intensive researches in Malware evasion techniques and penetration testing of electronic voting systems.

I do have experience in security testing since I have been performing penetration testing on several US electronic voting systems. I’ve also been encharged of testing uVote voting system from the Italian Minister of homeland security. I met Palantir Technologies where I was introduced to the Intelligence Ecosystem. I decided to amplify my cybersecurity experiences by diving into SCADA security issues with some of the biggest industrial aglomerates in Italy. I finally decided to found Yoroi: an innovative Managed Cyber Security Service Provider developing some of the most amazing cybersecurity defence center I’ve ever experienced! Now I technically lead Yoroi defending our customers strongly believing in: Defence Belongs To Humans

Edited by Pierluigi Paganini

(Security Affairs – Jason, APT34)

[adrotate banner=”5″]

[adrotate banner=”13″]