Monthly Archives: March 2016

Where’s Jack, updated

A few changes and an addition- In the upcoming weeks and months I’ll be speaking at the following events:

InfoSec Southwest, Austin, April 8-10

Sayers’ #Curio Technology Summit, Chicago, April 13

BSides Calgary, April 28-29

ISSA-LA Summit, May 19-20

IT-PRO, Seekonk MA, June 15

ISSA-NE, Waltham MA, July 12

I will not be speaking there, but I will be at the NIST Cyber Security Framework Workshop at NIST in Gaithersburg, MD- if you’re going to be there please say hello if you see me.

And I’m sure I’ll be at a few more.  See you on the road.

 

Jack

CVE-2016-1001 (Flash up to 20.0.0.306) and Exploit Kits





Two weeks after Flash patch,  two months after last Flash exploit integration in Angler, on the 2016-03-25 Angler EK, in some threads, is starting to send an exploit to Flash Player 20.0.0.270 and 20.0.0.306

I tried multiple configuration but I was not able to get exploited. The following day I got successful infections with Flash 20.0.0.270 and 20.0.0.306.

Angler EK :
2016-03-25

The CVE here has been identificated as CVE-2016-1001 by Eset and Kaspersky (Thanks)
2016-03-26 - Angler EK successfully exploiting Flash 20.0.0.306 in Internet Explorer 11 on Windows 7

Fiddler sent to VT here.
Hash of the associated SWF fwiw : b609ece7b9f4977bed792421b33b15da

NB : this is just "one" pass.  Angler EK can be used to spread whatever its customers want to spread .
Selected examples I saw in the last 4 days : 
Teslacrypt (ID 20, 40,52, 74 ,47) , 
Locky (affid 14 - 7f2b678398a93cac285312354ce7d2b7  and affid 11 - f417b107339b79a49e4e63e116e84a32), 
GootKit b9bec4a5811c6aff6001efa357f1f99c, 
Vawtrak  0dc4d5370bc4b0c8333b9512d686946c
Ramnit 99f21ba5b02b3085c683ea831d79dc79
Gozi ISFB (DGA nasa) 11d515c2a2135ca00398b88eebbf9299
BandarChor, (several instances, ex f97395004053aa28cadc6d4dc7fc0464 - 3c9b5868b4121a2d48b980a81dda8569 )
Graybird/LatentBot f985b38f5e8bd1dfb3767cfea89ca776
Dridex - b0f34f62f49b9c40e2558c1fa17523b5 (this one was 10 days ago..but worth a mention)
Andromeda (several instances)
and obviously many Bedep threads and their stream of PE (evotob, reactorbot (several instances), Tofsee, Teslacrypt,Kovter, Miuref)

Edit 1: 2016-03-29 -  I was mentioning 2016-1010 as a candidate but it's not. Modified with the correct CVE ID provided by Eset and Kaspersky..

Debunking debunking, part 1

Things need to be proven, or disproven. Urban legends need debunking.  But unless you dig into the history and have some context you may be wasting your time.  And if you have the context, you can make your case more convincingly.

Let’s venture into automotive lore for two examples.  First, a simple one- there’s a longstanding belief that you should never place a battery on bare concrete or it will damage the battery, or at least cause it to discharge.  You regularly see shops with batteries on scraps of plywood to this day.  I had this “debunked” at a manufacturer’s tech training many years ago, one of the instructors put a fully charged battery on the bare floor and the beginning of a week of training and it was fully charged at the end of the week.  End of story, right?  Well, not quite. 

First, the school was new and well equipped, it even had infrared heating, so the concrete floors were always warm, as opposed to the cold, damp floors many garages have throughout the winter.  Putting a modern battery on a cold damp floor really won’t hurt the battery- but cold batteries don’t release their power as well as warm ones, so putting a marginal battery on the floor could make it weak enough that it won’t start a car without being charged.

Second, above I said:

“Putting a modern battery on a cold damp floor really won’t hurt the battery”

The word “modern” is key to this legend.  In ye olden days car battery cases were made of “sealed” wood, then of natural rubber- both of which were somewhat porous.  Concrete is very good at wicking moisture, so putting one of these old batteries on concrete could really discharge it and suck water out of the battery.  Knowing this backstory means you can make a more convincing argument when faced with this particular legend.

Later, I’ll dive into one that has been “debunked” on TV and in universities.  By people who apparently don’t get the significance of context.

 

Jack

What it means to be an OSCP reloaded

In our recent blog post  "What it means to be an OSCP" we asked OSCPs to share their experience of what it means to have earned this certification and we received many tales of hardship and reward. Mike Benich sent in an entry that we felt very much captured the essence of the Offensive Security mentality; that the path to OSCP is challenging, stressful, and demanding, but the results leave you with much more than technological expertise.

Kali Linux 2.1.2 ARM Releases

The time has come for yet another Kali ARM image release with new and updated images. Our collection of supported ARM hardware grows constantly with new images from Raspberry Pi 3, Banana Pi and Odroid-C2, with the latter being our first real arm64 image. We're really excited about our new arm64 build environment and hope to see more 64bit ARM devices running Kali in the future. Feel free to visit our Kali Linux ARM downloads page to get the latest goodness.

More on Purple Teaming

I wanted to add a bit more context/info/explanation on Purple Teaming after publishing the Ruxcon slides as well as Facebook and Twitter interactions on that topic.

What is Purple Teaming?

Currently, there are as many definitions for Purple Teaming as there are talks and blog posts on the subject but I'm going to throw mine in as well.

Purple Teaming is "conducting focused pentesting (up to Red Teaming) with clear training objectives for the Blue Team."

The clear training objectives (aka a plan to eventually get caught) for the Blue Team is what differentiates Purple Teaming from typical Red Teaming. By its very nature, Red Teaming is making a HUGE attempt not to get caught. You are pulling out all the tips & tricks and big boy tools NOT to get caught.  With Purple Teaming, you have a plan to create an alert or event in the event the Red Team is not detected by the Blue Team during the Red Team process so the Blue Team can test their signatures and alerting and execute their incident response policies and procedures.

It isn't a "can you get access to X" exercise it is a "train the Blue Team on X" exercise. The pentesting activities are a means to conduct realistic training.

A couple practical examples:

The Blue Team has created alerts to identify Sysinternals PsExec usage in the enterprise.  The Red Team would at some point use PsExec to see if alerts fire off and the Blue Team can determine which hosts were accessed or pivoted from using PsExec.  The Red Team could also make use of all the PsExec alternatives (winexe, msf psexec, impacket, etc) so the Blue Team could continue to refine and improve their monitoring and alerting.

Another scenario would be where the Blue Team manager feels like the team has a good handle on the Windows side of things but less so on the OSX/Linux side of the house.  The manager could dictate to the Red Team that they should stay off Windows Infrastructure to identify gaps in host instrumentation and network coverage for *nix types hosts and also to force incident response on OSX or Linux hosts.

Another example could be to require the Red Team not to utilize freely available Remote Access Trojans such as Metasploit or powershell Empire. Instead they could ask that the Red Team purchase (or identify a consultancy that already uses) something like Core Impact or Immunity's Innuendo or find a consultancy that has their own custom backdoor to spice things up.

Thoughts?


Other Purple Teaming resources (in no particular order):

http://www.slideshare.net/beltface/hybrid-talk
http://www.slideshare.net/HaydnJohnson/purple-view-56169114
http://www.slideshare.net/denimgroup/b-sides-san-antonio-albert-campa-denim-group
http://www.slideshare.net/alienvault/security-by-collaboration-rethinking-red-teams-vs-blue-teams-cuispa-final-22015
https://files.sans.org/summit/hackfest2014/PDFs/Hacking%20to%20Get%20Caught%20-%20Raphael%20Mudge.pdf


Breaking Down the Malware Behind the Ukraine Power Outage

Security researchers recently discovered that the power outage in the Ukraine in December was caused by a malware and identified as an evolved version of BlackEnergy. This Trojan, dating back to 2007, was a popular malware that was previously sold in Russian underground sites. However, its design and architecture changed from performing simple HTTP DDos attacks to modular functional strategy implementation. The latest version of this Trojan is now capable of dropping rootkits, performing stealthy approaches and backdoor commands via a CnC server. It is also worth noting that it is highly speculated to be utilized by a group of attackers that are against the government of Ukraine. Since Stuxnet, this BlackEnergy cyberattack is another of its kind since it also managed to sabotage an industrial sector and that the group responsible for the power outage was also linked to the Trojan found in the mining and railway sector of Ukraine.

Industrial systems typically electrical, power, oil or water uses Industrial Control Systems (ICS), which are used for control, supervision and data collection. Usually, the ICS are on an isolated network and, although still part of the network, rarely have limited access to the internet. It is interesting how BlackEnergy managed to get inside these systems. Later during our analysis, we will gain insight on what happened and how the group managed to infiltrate the network from the initial stage of the attack via a phishing email.

This blog will focus on the analysis of BlackEnergy, parts of its core components, as well as how ThreatTrack’s ThreatAnalyzer and ThreatSecure provide us the information needed for data intelligence gathering. We’ll leave the analysis of the plugins that BlackEnergy utilized for another separate blog.

This research also aims to provide information on (1) how to emulate the attack by dissecting each stage of the process and (2) show how to utilize ThreatTrack’s newest line of threat identification products to mitigate and lessen the probability that these types of outbreaks might happen to you or your company. We’ll begin the analysis using the two samples that we have.

Md5: 97b7577d13cf5e3bf39cbe6d3f0a7732

  • Type: XLS (Microsoft Excel file)
  • First seen: 8/16/2015

Md5: e15b36c2e394d599a8ab352159089dd2

  • Type: DOC (Microsoft Document file)
  • First seen: 1/22/2016

BlackEnergy’s method of arrival is via a spear-phishing email containing a malicious attachment. We can emulate this by attaching the samples that we have on an email and send it inside our network. There has been a lot of debate as to how the attachment(s) was/were executed since, for this version of BlackEnergy, no exploits of Office have been seen. The only thing we know is that somehow a person inside executed the document file(s), whether by social engineering or an insider.

Using ThreatTrack’s ThreatSecure Network and ThreatSecure Email, we can see that it was identified as something malicious when entering the network and also via email. The system changes that it will be performing can be seen under behaviors. The IP entry indicates the IP address of a remote server that it is trying to beacon to. Since this sample is already a few months old, and news of this attack has already been widespread, it only makes sense that the server is already down.

TSN_Excel

Fig 1: TSN catching the XLS attachment

docTSN_identified

Fig 2: TSN catching the DOC file

tse_unreviewed

Fig 2.1: ThreatSecure Email (TSE)

tse_details

Fig 2.2: Submit for Remediation

A cool feature of ThreatSecure Network is that, once a threat has been identified, any connection made to the target computer will be monitored and can be seen in the ThreatSecure Network UI  called ThressionsTM. Using these Thressions, users will be alerted that an attack is happening or has happened and, depending on their settings, will be able to block a said network session. Fig 2.1 and Fig 2.2 above show that the file we are analyzing was caught by ThreatSecure Email, and upon user’s request can be submitted for remediation to remove the system changes done by the malware.

It is a good practice to find out what the malware does in overview prior to getting deep in the assembly breakdown. There are a couple of ways we can do this. You can use an infected machine and the tools available on the net to see what the malware does upon execution. But this would take time and effort to set up, and there’s a much faster and easier way we can do this: Use a sandbox.

ThreatTrack’s dynamic malware analysis sandbox ThreatAnalyzer reveals the behaviors not normally seen on normal programs.

We started with the DOC file (e15b36c2e394d599a8ab352159089dd2) and the XLS (97b7577d13cf5e3bf39cbe6d3f0a7732), and both showed the same behavior:

  • Dropped the following files
    • %Temp%\vba_macro.exe
    • LNK file (windows shortcut) pointing to the DOC file
    • %Application Data%\FONTCACHE.DAT
    • %User%\NTUSER.LOG
    • %Common Startup%\<adapter name>.LNK file
  • Creates a named pipe
    • Pipe\{AA0EED25-4167-4CBB-BDA8-9A0F5FF93EA8}
  • Executed the following processes, some of the spawned multiple times
    • Vba_macro.exe
    • Cmd.exe
    • Attrib.exe
    • Ping.exe
    • Rundll32.exe %Application Data%\FONTCACHE.DAT, #1
    • %Program Files%\iexplore.exe
  • A screenshot showing what the document looks like when opened (DOC and XLS)
  • Created/Modified the following registry
    • Software\Microsoft\Internet Explorer\Main Check_Associations
    • Software\Microsoft\Internet Explorer\InformationBar FirstTime
    • Software\Microsoft\Internet Explorer\New Windows PopupMgr
    • Software\Microsoft\Internet Explorer\PhishingFilter Enabled
    • Software\Microsoft\Windows\CurrentVersion\Internet Settings\Cache Persistent
    • Software\Microsoft\Internet Explorer\TabbedBrowsing WarnOnClose
    • Software\Microsoft\Internet Explorer\TabbedBrowsing WarnOnCloseAdvanced
    • Software\Microsoft\Internet Explorer\Main DisableFirstRunCustomize
    • Software\Microsoft\Internet Explorer\Recovery NoReopenLastSession
    • Software\Microsoft\Internet Explorer\Main NoProtectedModeBanner
    • Software\Microsoft\Internet Explorer\TabbedBrowsing
    • Software\Microsoft\Internet Explorer\Recovery
  • Attempted to connect to a remote server
    • 5.149..254.114
    • Usage of RPCRT4.DLL
TA_processes

Fig 2.3: ThreatAnalyzer showing processes spawned by the DOC file

Looking a bit deeper

Now that we have an overview of what the samples are doing, we’ll do some classic reverse-engineering.

Although the two samples have different hashes and file formats (the one is a word document file and the other an excel sheet) they are, in basic sense, the same.

Both have a malicious macro script embedded in them and both are trying to deceive the user from disabling the macro security settings that is enabled by default. A fake Microsoft Office message appears in Russian, stating “This document was created by a newer version of Microsoft office. Macros must be enabled to display the content of the document.”

Depending on the security settings of Microsoft Office (high, medium or low), the image on Fig 4 will be displayed. If a user somehow chose to disable the macro security or is on a low security level, the malicious scripts previously mentioned will be executed immediately.

security_macro

Fig 3: Security on medium settings

Looking inside the VB macro, the code are fairly straightforward:

  • Declares a series of byte array
  • Save it in a file located in the %TEMP% directory
  • Execute the said file using the function SHELL
Fig 4

Fig 4: Byte array declaration (MZ)

 

Fig 5: Byte array declaration (PE)

Fig 5: Byte array declaration (PE)

Fig 4 shows the value 77, 90 in array a (1). Converted to hex, that is 0x4D, 0x5A (MZ), which is a strong indicator that these sequence of array is an executable. This is further verified in Fig 6, where we see 80, 69 that, when converted to hex, results in 0x50, 0x45 (PE).

Automatic execution is achieved by doing the following:

Fig 6: Byte array declaration (PE)

Fig 6: Byte array declaration (PE)

Fig 7. Deobfuscated macro

To put it simply, Fig 7 tells us that it will save the byte array into a file named vba_macro.exe located in %TEMP% directory and execute it using the Shell function.

Vba_macro.exe

According to the results from ThreatAnalyzer, Vba_macro.exe will spawn a file named FONTCACHE.DAT and several other processes. Looking inside the vba_macro executable, it seems it is heavily obfuscated at its entry point. It is posing as a file with an original name of packet.dll and is exposing several functions similar to that of being used by WinPCap. The weird thing is that although the function names are similar to that of a legit packet.dll located at the system directory (assuming WinPCap is installed), the assembled code is garbage, except for the first function, which is probably the deobfuscator code.

packet_dll_comparison

Fig 8: Note the similarities and the difference between the two.

The primary purpose of this file is to stage the next part of the infection process, which is to execute FONTCACHE.DAT.

Upon execution, this file reconstructs its code in an allocated part of memory and writes parts of itself in a separate file, the FONTCACHE.DAT, in the Application data folder. The GetAdaptersInfo API is used to get the name of the network card in use, use that as a file name for the .LNK, which is a windows shortcut file that will execute another program indicated on its path. On this case, it uses this method to ensure that the program it points to %windir%\System32\rundll32.exe “C:\Documents and Settings\Administrator\Local Settings\Application Data\FONTCACHE.DAT” will always get started upon boot up.

It deletes the credential named MCSF_Config before executing FONTCACHE.DAT using rundll32 with #1, indicating to execute the first ordinal function. This version of BlackEnergy uses the said credential to store its configuration, and in order to ensure that it will have the latest config, it deletes it prior to executing FONTCACHE.DAT.

creddelete_shellexecute

Fig 9: CredDeleteA and ShellExecute

It will call the following command line shell commands

cmd /s /c “for /L %i in (1,1,100) do (del /F “%TEMP%\vba_macro.exe” & ping localhost -n 2 & if not exist “%Application Data%\FONTCACHE.DAT” Exit 1)

cmd /s /c “for /L %i in (1,1,100) do (attrib +h “%TEMP%\vba_macro.exe” & del /A:h /F “%TEMP%\vba_macro.exe” & ping localhost -n 2 & if not exist “%Application Data%\FONTCACHE.DAT” Exit 1)

FONTCACHE.DAT

Fontcache.dat is executed using rundll32, a way for Windows to run compiled libraries. It has an argument of #1, which means to run the first ordinal in its exported functions.

In an attempt to make a researcher’s life more difficult and in order to slow down the time to fully analyze the malware, the authors decided to obfuscate, again, this piece of malware.

We’ll get a bit deeper by trying to unpack the malware using old methods. It is common knowledge for malware analysts to set a break point to common memory allocating APIs, such as VirtualAlloc and LocalAlloc, and see whether the malware is trying to unpack part of itself in memory; however, this particular sample uses RtlAlloc and HeapAlloc to copy parts of itself little by little.

After decryption and some initializations, it will enter its main loop.

mainloop_flow_letters

Fig 10: Chart of main function of FONTCACHE.DAT

(A) Attempts to read the current user’s credential named MCSF_Config using CredReadA API. The one that will be read is actually an encrypted buffer that will be written by the malware in function (B). This encrypted buffer will be decrypted twice and will contain information like the CnC server URL, bot version, build type and some other strings that will be appended to locally gathered data.

decrypted_configuration

(B) Reads the data in the .CDATA section of FONTCACHE.DAT and overwrites the current user’s credential with that blob. This is achieved via CredWriteA API. This part also gathers local information about the target system and saves it for later use.

(C) Responsible for modifying the settings for Internet Explorer in the registry.

    • Software\Microsoft\Internet Explorer\Main Check_Associations
    • Software\Microsoft\Internet Explorer\InformationBar FirstTime
    • Software\Microsoft\Internet Explorer\New Windows PopupMgr
    • Software\Microsoft\Internet Explorer\PhishingFilter Enabled
    • Software\Microsoft\Windows\CurrentVersion\Internet Settings\Cache Persistent
    • Software\Microsoft\Internet Explorer\TabbedBrowsing WarnOnClose
    • Software\Microsoft\Internet Explorer\TabbedBrowsing WarnOnCloseAdvanced
    • Software\Microsoft\Internet Explorer\Main DisableFirstRunCustomize
    • Software\Microsoft\Internet Explorer\Recovery NoReopenLastSession
    • Software\Microsoft\Internet Explorer\Main NoProtectedModeBanner
    • Software\Microsoft\Internet Explorer\TabbedBrowsing
    • Software\Microsoft\Internet Explorer\Recovery

The function also creates a separate thread that initiates the RPC communication over named pipes. The mentioned named pipe is the method of communication of different BE 3 plugins over the same network.

      1. Pipe\{AA0EED25-4167-4CBB-BDA8-9A0F5FF93EA8}

(D) Creates a file named NTUSER.LOG. Currently, due to the way it was programmed, it only creates a 0 byte file.

(E) Forms the message that will be sent over to its CnC server. It contains the following information:

      • B_id : BotID, comprises of <computername> _<unique bot identifier>
      • B_gen : generation of bot, on this case “release”
      • B_ver : Bot version, “2.2”
      • Os_v : target system OS version, “2600” (Build version of Windows XP)
      • Os_type: OS type, “0”

Using CryptBinaryToString, it “encrypts” the data that will be sent over the network and sent to its CnC server as POST data as the body parameter

post_data

(F) Creates an instance of Internet Explorer in the background using CoCreateInstance API. Since the settings of IE were already modified, no GUI will be seen, and it will be running under svchost.exe.

  • D30C1661-CDAF-11D0-8A3E-00C04FC9E26E using this GUID, an empty instance of IE will be called as it is the default handler of IWebBrowser2 interface.
  • Connects to http://5.149.254.114/Microsoft/Update/KC074913.php as an RPC client to send the information to a remote server.

rpc_cnc_connection

(G) Assuming a connection to the remote server has been made, it accepts 4 basic commands:

  • Delete – deletes a specified file
  • Ldplg – loads a plugin
  • Unlplg – unload a plugin
  • Dexec – download and execute a binary file

Using this, it has made itself modular as it can download and execute different plugin based on what type of attack will be performed. BlackEnergy has already been linked to several found plugins that also uses the named pipe mentioned above as inter-process communication, locally or even over the local network.

It is believed that these backdoor commands are the ones responsible for the attack that happened. The authors would upload new plugins, execute them and, after the damage has been done, delete the traces. These are (but not limited to):

      • Input/Output (IO) operations, deleting files and wiping away traces
      • Gathering system information
      • Keyloggers
      • Password stealers
      • Taking of screenshots
      • Remote access, SSH or RDP

After which, it will sleep for X number of seconds, depending on the one indicated on its configuration data and attempt to send the information and accept new commands from the CnC server.

Summary

overall_flow

Fig 11: Simplified overall flow of BlackEnergy 3

Point of entry is using a targeted spear-phishing email with a malicious attachment. Once it has been executed, the malware would be able to download and install new plugins. Communication between the core malware module and plugins are achieved through RPC communication. This is employed since most ICS are on an isolated network. Even if the target systems are on a network that does not have internet connection, the malware would still be able to ex-filtrate the data, install new plugins and control the systems using RPC named pipes over SMB. Simplified diagram on Fig 11.

The post Breaking Down the Malware Behind the Ukraine Power Outage appeared first on ThreatTrack Security Labs Blog.

Ransomware.OSX.KeRanger samples


Research: New OS X Ransomware KeRanger Infected Transmission BitTorrent Client Installer by Claud Xiao

Sample credit: Claud Xiao


File information

d1ac55a4e610380f0ab239fcc1c5f5a42722e8ee1554cba8074bbae4a5f6dbe1 
1d6297e2427f1d00a5b355d6d50809cb 
Transmission-2.90.dmg

e3ad733cea9eba29e86610050c1a15592e6c77820927b9edeb77310975393574 
56b1d956112b0b7bd3e44f20cf1f2c19 
Transmission

31b6adb633cff2a0f34cefd2a218097f3a9a8176c9363cc70fe41fe02af810b9
14a4df1df622562b3bf5bc9a94e6a783 
General.rtf

d7d765b1ddd235a57a2d13bd065f293a7469594c7e13ea7700e55501206a09b5 
24a8f01cfdc4228b4fc9bb87fedf6eb7 
Transmission2.90.dmg

ddc3dbee2a8ea9d8ed93f0843400653a89350612f2914868485476a847c6484a
3151d9a085d14508fa9f10d48afc7016 
Transmission

6061a554f5997a43c91f49f8aaf40c80a3f547fc6187bee57cd5573641fcf153 
861c3da2bbce6c09eda2709c8994f34c 
General.rtf



Download