Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.
SECRE
T//
NOFORN
Pique Analysis Report
20150904-275-Cisco Rombertik
Ra
y
theon Blackbird Technolo
g
i
es,
Inc. 1 04 Se
p
tember 2015
Use or disclosure of data contained on this sheet is su
bje
ct to the restrictions on the title
page
of this document.
SECRE
T//
NOFORN
1.0 (U) Analysis Summary
(S//NF) This report is based on a blog post from Cisco on a piece of malware known as
Rombertik. Rombertik uses heavy obfuscation to prevent static and dynamic analysis. If
Rombertik detects it is being analyzed it will proceed to destroy the host MBR and if that isn’t
possible it will encrypt all documents in C:\Documents and Settings\Administrator.
(S//NF) As reported in the SentinelOne blog (Pique report 20150904-275-SentinelOne-
Rombertik), the Cisco blog report states that 97% of the packed malware is “junk” code used to
make static and dynamic code analysis difficult. Rombernik is distributed via spam and spear
phishing email campaigns.
(S//NF) Upon execution, Rombertik stalls and then will run through a set of checks to determine
if it’s running in an analysis environment/sandbox. Once these checks are complete the malware
proceeds to decrypt and install itself. Once installed, it will launch a second copy of itself. Before
launching its credential stealing routines, it does one last check of memory to see if it’s being
debugged or running in a sandbox. If it detects it’s being debugged or running in a sandbox, it
acts destructively by overwriting the MBR or encrypting the Administrator files.
(S//NF) Rombertik uses a couple of interesting anti-sandbox/anti-analysis techniques. Many anti-
sandbox methods involve relatively long sleep() cycles to wait-out the sandbox. Instead of using
sleep(), Rombertik accomplishes the same effect but without calling sleep(). Instead, Rombertik
writes a byte of random data to memory 960 Million times. This technique has several
advantages in defeating sandboxes, it accomplishes a sleep() delay tactic without calling sleep().
Sandboxes won’t be able to immediately determine the application is intentionally stalling
because it isn’t sleep()ing. The other advantage is the repetitive writing will flood application
tracing tools. We recommend this anti-sandbox technique be developed as a PoC.
(S//NF) After stalling via random byte memory writing, Rombertik checks to see if any analysis
tools have modified code in the ZwGetWriteWatch() API. It does this by calling
ZwGetWriteWatch() with invalid arguments and if a specific return value isn’t seen Rombernik
terminates. This is an effective anti-analysis technique because sandboxes suppress errors
returned from API calls. We recommend this anti-sandbox technique be developed as a PoC.
(S//NF) After the sandbox check is completed, Rombertik calls OutputDebugString() 335,000
times as an anti-debugging technique. Finally, the malware checks the executing process for
strings indicating analysis platforms, strings such as “malwar”, sampl”, “viru”, and “sandb.”
(S//NF) If all the anti-analysis checks pass, Rombertik completes the installation and proceeds to
hook browser APIs that handle plain-text data in order to harvest website username/password
combinations.
(S//NF) We recommend the following anti-analysis techniques be developed as PoCs:
Rombertik’s method for stalling to wait-out sandboxes by writing a random byte of data to
memory 960 Million times.
Rombertik’s method for checking anti-analysis by checking to see if ZwGetWriteWatch()
returns the expected value.