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.

Observables

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
URL: 23.111.188.254:31337

Filename: 2.exe
MD5: 1AB7415C4A38F45085857FB9E6BD2069
Size: 72KB
URL: 23.111.188.254:4013

Filename: 3.exe
MD5: 6D1029FABF4D314065E3B33AC02ACEA6
Size: 1.14MB
URL: 23.111.188.254:22572

Filename: 4.exe
MD5: 9B79D2C612E4EAFB9034FD652F5A20EA
Size: 1.14MB
URL: 23.111.188.254:15892

Filename: Aifc0CC.exe
MD5: E967102AA181290B3A2BB68AD36E285A
Size: 72KB
URL: 45.114.116.192:13187

Filename: GFDXaoPXi.exe
MD5: 81B9EA03264EA0A2B65B36EACB05B465
Size: 72KB
URL: 23.111.188.254:7605

IPs/Domains

78.37.191.149 – pppoe.avangarddsl.ru
178.70.232.38 – avangarddsl.ru
178.70.225.165 – avangarddsl.ru
178.70.149.30 – avangarddsl.ru
23.111.188.254 – hvvc.us
45.114.116.192 – brilliantangle.com

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 pyxswf.py. Nothing. I then used rtfobj.py 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 rtfdump.py (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:

AFB6BDC4CBD2D9E0E7EEF5FC030A11181F262D343B420050575E656C737A81888F96
9DA4ABB2B9C0C7CED5DCE3EAF1F8FF060D141B222930373E454C535A61686F767D84
8B9299A0A7AEB5BCC3CAD1D8DFE6EDF4FB020910171E252C333A41484F565D646B72
7980878E959CA3AAB1B8BFC6CDD4DBE2E9F0F7FE050C131A21282F363D444B525960
676E757C838A91989FA6ADB4BBC2C9D0D7DEE5ECF3FA01080F161D242B323940004E
555C636A71787F868D949BA2A9B0B7BEC5CCD3DAE1E8EFF6FD040B121920272E353C
434A51585F666D747B828990979EA5ACB3BAC1C8CFD6DDE4EBF2F900070E151C232A
31383F464D545B626970777E858C939AA1A8

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

Wild Wild West – 11/2016

It’s been awhile since I updated this; my apologies for the delay to those who have been asking.

Many thanks to Kafeine for his expertise and invaluable feedback!

wildwildwest_1116

Posted in Exploit Packs | Comments Off on Wild Wild West – 11/2016