Deobfuscating PHPJiami

I was sent a PHP script that was protected by PHPJiami which you can find here. PHPJiami is a decent PHP obfuscator that appears to be able to bypass several online deobfuscators. Here’s what the script looks like:

When you run it, you can see what the protected script does.

At the top there’s a comments section. Let me change the uppercase “P” in “PHP” to lowercase.

Now when I run the script, nothing happens. This means there’s some kind of anti-tampering function in the script.

Let me clean up the script so we can see what it’s doing. If you look at the second function, you can see what looks like variable assignments.

At the bottom of the script, you can see a blob of obfuscated text. This is probably where the prize is.

After studying this a bit, I go back up to the second function and echo out the variables to see what they contain (look at the comments). That last line is interesting as it reads a copy of itself.

The section right below that has some interesting variables as well. It looks like it’s using MD5 to ensure the script isn’t modified. If all is good, the blob at the bottom gets uncompressed, rot13’d, etc.

Although I have only have a brief understanding of what the script does, I think I have enough to deobfuscate the blob. Since I cannot modify this script to make it cough up the prize, I can trick it into thinking that the script hasn’t changed by making it read a copy of itself (I call this the “reflection technique”).

Here’s the two changes made to the beautified version.

On the actual script or other PHPJiami scripts, all I do is search for strings that are at the end of the previous line which is ():”; Then put in the reference to the original script. From there, I search for “return” and put an echo there.

When the script is run, I get a result which looks something like this which doesn’t mean too much.

But when you view the source, you can see the original source code.

I just did a quick check to see if anyone else did a deobfuscation write-up and I came across this Chinese site.

It describes a few methods but one technique they offered caught my eye:

If you execute this, you get the deobfuscated script and it’s so easy to do. Might even work on a bunch of other scripts too.

Scroll down to the very bottom and you’ll see a long base64 string. If you decode this, you get the original script which is the same version I got using my, more difficult, reflection technique. Oh wellz.

Always nice to have multiple methods to use since their obfuscation method will probably be upgraded in the future.

Posted in Malscript | Tagged , , | Comments Off on Deobfuscating PHPJiami

ConverterNET v0.1 Released

I spent the past several months porting Converter to the .NET Framework and am finally able to release a public version of it.

Many of the original functions are present and I’ve added a few more things to the menu. Several conveniences have also been included that may not be very obvious:

+ Forms are non-modal so you can have multiple forms open at once
+ Many forms can be maximized
+ Many forms have split containers that you can resize
+ Context menu have been added to key textboxes
+ Textboxes are using a monospaced font

The Convert Binary function has been changed. You can choose to load a binary or text file and convert the file appropriately. If you want to XOR or shift the files then choose “Transform Only” then enter your comma-delimited text or hex key.

The Key Search/Convert function has also changed a bit. Specifically you can choose:

+ Single key (e.g. abc ^ x)
+ Multi-key (e.g. a ^ x, b ^ y, c ^ z)
+ Multi-key sub-loop (e.g. a ^ xyz, b ^ xyz, c ^ xyz)
+ Multi-key step # (e.g. a ^ (xyz % step), etc ).

You can get ConverterNET (32-bit and 64-bit binaries are included) from here. If you encounter any bugs, please let me know.

Posted in Tools | Tagged , | Comments Off on ConverterNET v0.1 Released

Not Your Typical Ransomware Infection

An analysis of an infected PC revealed that an attacker used several NSA tools just four days after the Shadow Brokers’ dump then it burned the PC with ransomware when they were done with it. This blog post by Secdo may be related to this one but I can’t be sure.

I was asked to assist with an infected PC that had already been turned off. The ransomware encrypted the usual file extensions as well as .exe, .dll, .sqlite, .log, .xml, .dat, etc making it extremely difficult to piece together the activity that had taken place earlier.

On 4/18/17, a remote user logged into the computer via RDP and proceeded to execute a program called “key.exe” which dropped files in “C:\ProgramData\MicrosoftHostDLL\” including synchosted.exe (which is turned out to be NSSM – The non-sucking service manager). A new remote admin account called “backup1” was created and the password written to the info.ini file (and c:\info.txt).

The attacker downloaded several tools to the downloads folder and disabled anti-virus and added an exclusion for c:\users\backup1 in Windows Defender.

Other tools were installed as well such as UniversalTermsrvPatch-x64 and Advanced IP Scanner.

Based on the evidence, the following NSA tools were used by the attacker:

+ FuzzBunch (exploit framework)
+ Architouch (SMB recon)
+ EternalBlue (SMB exploit)
+ DoublePulsar (backdoor)
+ DanderSpritz (event log deleter, password stealer, screengrabber, keylogger)
+ PeddleCheap (shellcode/DLL injector)

When FuzzBunch is run, log files are created which provide a history of the operator’s activities. However, the ransomware program encrypted these files.

There were some files left untouched for some reason and I was able to collect details that show whether an attempt was successful or not.

One successful compromise prompted the attacker to download and install OWASP-ZSC to compile shellcode and use PeddleCheap to push that onto the machine. Each attempt caused the PC to crash. Digging into the crash dumps yielded the shellcode source.

When this failed, other attempts were made to install malware.

I tried to get the payload from the above site but it was no longer available. I found something in Google’s cache that seemed to match the file names.

The attacker then downloaded executables onto the desktop and tried to push them onto the other PC which failed. Having given up, the attacker trashed the PC by executing ransomware known as “Global Imposter”.

It appears that this attacker was figuring out how to use the NSA tools and eventually with enough practice s/he is going to get good at it. Others will too so we will probably start seeing a higher level of attacks — attacks using military-grade implants that don’t leave a whole lot of traces behind. Good luck to all of us.


Filename: key.exe
MD5: EECD77E9D522F3BA9022AC55487D98F1
Size: 1.19MB

Filename: synchosted.exe
MD5: E1D51EAE61D112CB00F8F9CED4D7294C
Size: 331KB

Filename: genpwd.exe
MD5: 0569047CAD5FFE8C40290960FFDCFDA1
Size: 808KB

Filename: local.exe
MD5: B1BA95F7F943E424D562AA5BB255ADC5
Size: 530KB

Filename: 1.exe
MD5: 227837783DFC1C2B3575746478CC133E
Date: 7KB

Filename: 2.exe
MD5: 1AB7415C4A38F45085857FB9E6BD2069
Size: 72KB

Filename: 3.exe
MD5: 6D1029FABF4D314065E3B33AC02ACEA6
Size: 1.14MB

Filename: 4.exe
MD5: 9B79D2C612E4EAFB9034FD652F5A20EA
Size: 1.14MB

Filename: Aifc0CC.exe
MD5: E967102AA181290B3A2BB68AD36E285A
Size: 72KB

Filename: GFDXaoPXi.exe
MD5: 81B9EA03264EA0A2B65B36EACB05B465
Size: 72KB

IPs/Domains – – – – – –

Posted in Malware | Tagged , , | Comments Off on Not Your Typical Ransomware Infection

Wild Wild West – 05/2017

Another update to the exploit kit scene. There’s been some changes but nothing very exciting. We can’t put our guards down however since this could change very easily.

If anyone cares to share the source for anything in the most wanted category, I would love to study it. And yes that includes Eris / Solar / Neptune.

Big thanks to Kafeine for his input as I couldn’t have done this without him!

Posted in Exploit Packs | Comments Off on Wild Wild West – 05/2017

Static vs Dynamic Analysis and the Amusing Outcome

It all started with a malicious RTF document attached to an email and a request from reader Chris (thanks for your request and help!) to locate the embedded SWF object since it was believed to contain a hidden PE file.

The RTF document contained a 2012 exploit which is described here. The difference between the two documents is that this one contained a SWF file.

I proceeded to use oletools to search for SWF files using Nothing. I then used to dump all the objects.

I looked through the files and no SWF header. I also used OfficeMalScanner’s rtfscan and got the exact same objects and no SWF. I went back to each of the objects using a hex editor and I find the header…kind of.

The “FWS” header can be translated into hex as 0x465753 but in the file it shows up as “0x04657532”. It’s off by half-a-byte. I wrote a quick program that shifts the file by converting everything to hex, removing the first hex character at the beginning, padding the end with a null, then converting everything back into bytes.

Now I get the Flash file.

Chris suggested I use Didier Steven’s (with the latest fix — version 0.5) which gets the job done.

Using JPEXS you can see the deobfuscation routine of the embedded binary data.

I created another program to do some ad hoc XOR’ing and I find that the binary blob is another Flash file. You can read this TrustWave article on Sundown EK and use their Python script.

This embedded SWF file is reusing an exploit from Magnitude EK. You can read about that exploit here btw. No sign of a PE file.

Let me go back to the large object I dumped earlier and try to find the PE file using static analysis. At the top, I notice that this is the same marker as the one identified in the SecureList blog post. Looks like the PE file is here but it’s obfuscated.

I compare this file with the malware that gets dropped by the malicious RTF file and I can see that it lines up exactly and that the null bytes are left intact. Since nulls are present, I can rule out compression and modern encryption. That leaves shift and XOR as a possibility but since they ignored nulls, I can’t easily get the key.

What I need to find is a large contiguous blob without any nulls. Near the bottom of the PE file I come across padding strings. There’s other parts of the file I could use but this makes it quicker.

All I need to do is XOR the plaintext with the obfuscated portion and I can get the key. I use Converter’s Key Search/Convert and paste the values in and I get the result.

Here’s what the result looks like. It looks random but I’m hoping there’s a repeating pattern here. That pattern would represent the XOR key.

Here’s a trick I do to find a pattern. I simply change the dimensions of the Notepad window and watch the pattern emerge. There it is!

So the repeating value appears to be 256 bytes long and looks like this:


Let me test this out with Converter. Ugh, so close!

After analyzing the results, I noticed that if a null character is present then it doesn’t rotate the key for the next loop. So I add a new option to Converter…and it works! It works on the decoy document embedded in this object file as well.

Now I wanted to find the shellcode and verify this using dynamic analysis.

One way is to open the document with Word, dump the memory, then look for that marker. Here’s the shellcode.

And here it is in the RTF document.

If you dissemble this, you find that the first part of the shellcode deobfuscates the second part. XOR’ing the second part with a value of 0xA6 reveals the PE decoding routine. I went ahead and XOR’d it then put everything together in IDA. But let me use a debugger instead…

Ah, it’s not a 256-byte XOR key! You can see that the shellcode deobfuscates the PE file using XOR with a starting value of 0xA8 then incrementing it by 0x07. If there’s a null byte then it skips that byte (and doesn’t increment the value). How simple.

So at the end of all this, it turns out that the 256-byte XOR key found during static analysis is the same result I got dynamically albeit the long way to the solution. Very amusing!

Note: If you look at the XOR key above, you’ll see that 0xAF + 7 = 0xB6 + 7 = 0xBD …etc. And when you get to the end, 0xA8 + 7 = 0xAF.

Update 03/01/2017 – To those who where asking, here’s the PE results from VirusTotal.

Posted in Malicious Email, Malscript | Tagged , , , , | Comments Off on Static vs Dynamic Analysis and the Amusing Outcome