Friday, June 8, 2018

DMOSK Malware Targeting Italian Companies

Today I'd like to share another interesting analysis made by my colleagues and I. It would be a nice and interesting analysis since it targeted many Italian and European companies. Fortunately the attacker forgot the LOG.TXT freely available on the dropping URL letting us know the IP addresses who clicked on the first stage analysed stage (yes, we know the companies who might be infected) . Despite what we did with TaxOlolo we will not disclose the victims IP addresses and so the companies which might be infected. National CERTs have been involved and they've got alerted.  Since we believe the threat could radically increase its magnitude in the following hours, we decided to write up this quick'n dirty analysis focusing on speed rather than on details. So please forgive some quick and undocumented steps.

Everything started from an eMail (how about that ?!). The eMail we've got had the following body.

Attack Path
A simple link to a drive ( drive.carlsongracieanaheim.com ) is beginning our first stage of infection. An eMail address is given as one parameter to the doc.php script which would record the IP address and the "calling" email  address belonging to the victim. The script forces the browser to download a .zip file which uncompressed presents to the victim a JSE file called: scan.jse.  The file is hard obfuscated. It was quite difficult to be able to decode the following stage of infection since the JavaScript was obfuscated through, at least, 3 different techniques. The following image shows the Obfuscated sample.

Second Stage: Obfuscated JSE
Unfortunately the second stage is not the final one. Indeed once de-obfuscated it we figured out that it was dropping and executing another file having the .SCR mimetype. From this stage it's interesting to observe that only one dropping URL was called. It's a strange behaviour, usually the attackers use multiple dropping URLs in order to get more chances to infect the victims. The found URL was the following one:

"url": "https://drive.carlsongracieanaheim.com/x/gate.php"

The JSE file dropped the Third Stage into \User\User\AppData\Local\Temp\38781520.scr having the following  hash: 77ad9ce32628d213eacf56faebd9b7f53e6e33a1a313b11814265216ca2c4745 which has been previously analysed by 68 AV but only 9 of them recognised as malicious generic file. The following image shows the VirusTotal analysis.



Third Stage: Executable SCR file


Unfortunately we are still not at the end of the infection Stage. The Third stage drops and executes another payload. It does not download and execute from a different dropping website but it drops from a special and crafted memory address (fixed from .txt:0x400000). The following image shows the execution of the Fourth Stage payload directly from the victim's memory

Fourth Stage: Dropped PE File
Following the analysis it has been possible to figure out that the final payload is something very close to ursnif which grabs victims email information and credentials. The following image shows the temporary file built before sending out information to Command and Controls servers.

Temporary File Before Sending data to Command and Control

Like any other ursnif the malware tries to reach a command and control network located both on the clearnet and on the TOR network. A following section will expose the recorded IoCs.

An interesting approach that was adopted by attackers is the black listing. We observed at least 3 black lists. The first one was based on victims IP. We guess (but we have not evidences on that) that the attacker would filtering responses based on Country in order to make possible a country targeted attack by blacklisting not-targeted countries. The following image shows the used temporary file to store Victim IP. The attacker could use this information in order to respond or not to a specific malware request.

Temporary File Storing IP Victim IP Address

A second black list that we found was on the dropping URL web site which was trained to do not drop files to specific IP addresses. The main reasons found to deny the dropping payload were three:
  • geo (Out of geographical scope). The threat is mainly focused to hit italy.
  • asn (internet service providers and/or cloud providers). The threat is mainly focused on clients and not on servers, so it would have no sense to give payload to cloud providers.
  • MIT. THe attacker does not want the dropping payload ends up to MIT folks, this is quite funny, isn't it ?
A small section of black listing drop payload  



The black lists are an interesting approach to reduce the chance to be analysed, in fact the black listed IPs belong to pretty known CyberSecurity Companies (Yoroi is included) which often use specific cloud providers to run emulations and/or sandboxes. 

Personal note: This is a reverse targeting attack, where the attacker wants to attack an entire set of victims but not some specific ones, so it introduces a blocking delivery of payload technique. End personal note.

Now we know how the attack works, so lets try to investigate a little bit what the attacker messed out. For example lets try to analyse the content of the Dropping URL. Quite fun to figure out the attacker let freely available his private key ! I will not disclose it .... let's say... for respect to the attacker (? really ?) 

Attacker Private Key !

While the used public certificate is the following one:

Attacker Certificate

By decoding the fake certificate the analyst would take the following information, of course none of these informations would be valuable, but make a nice shake of analysis .

Common Name: test.dmosk.local
Organization: Global Security
Organization Unit: IT Department
Locality: SPb
State: SPb
Country: RU
Valid From: June 5, 2018
Valid To: June 5, 2022
Issuer: Global Security
Serial Number: 12542837396936657430 (0xae111c285fe50a16

Maybe the most "original string", by meaning of being written without thinking too much from the attacker, on the entire malware analysis would be the string  "dmosk" (in the decoded certificate), from here the Malware name.

As today we observed: 6617 eMail addresses that potentially could be compromised since they clicked on First stage (evidences on dropping url). We have evidences that many organisations have been hit from this malware able to bypass most of the known security protections since it was behind CloudFlare and with not a specific bad reputation. We decided to not disclose the "probably infected" companies. Nation Wide CERTs have been alerted (June 7 2018) and together we will contact the "probably infected" companies to help them to mitigate the threat. 

Please update your rules, signature and whatever you have to block the infection.

PS: the threat is quite a bit bigger than what I described, there are several additional components including APK (Android Malware), base ciphers, multi stage obfuscators and a complete list of "probably infected" users, but again, we decided to encourage the notification speed rather than analysis details. 

Hope you might find it helpful.


IoC:
  • Dropurl:
    • https:// drive[.carlsongracieanaheim[.com/doc.php
    • https:// drive[.carlsongracieanaheim[.com/doc1.php
    • https:// drive[.carlsongracieanaheim[.com/x/gate.php
    • https:// drive[.carlsongracieanaheim[.com/1/gate.php
  • C2 (tor):
    • https:// 4fsq3wnmms6xqybt[.onion/wpapi
    • https:// em2eddryi6ptkcnh[.onion/wpapi
    • https:// nap7zb4gtnzwmxsv[.onion/wpapi
    • https:// t7yz3cihrrzalznq[.onion/wpapi
  • C2:
    • https:// loop.evama.[at/wpapi
    • https:// torafy[.cn/wpapi
    • https:// u55.evama[.at/wpapi
    • https:// yraco[.cn/wpapi
    • https:// inc.robatop.[at/wpapi
    • https:// poi.robatop.[at/wpapi
    • https:// arh.mobipot.[at/wpapi
    • https:// bbb.mobipot.[at/wpapi
    • https:// takhak.[at/wpapi
    • https:// kerions.[at/wpapi
    • https:// j11.evama[.at/wpapi
    • https:// clocktop[.at/wpapi
    • https:// harent.[cn/wpapi
  • Hash:
    • 067b39632f093821852889b1e4bb8b2a48afd94d1e348702a608a70bb7b00e54 zip
    • 77ad9ce32628d213eacf56faebd9b7f53e6e33a1a313b11814265216ca2c4745 jse
    • 8d3d37c9139641e817bcf0fad8550d869b9f68bc689dbbf4b4d3eb2aaa3cf361 scr
    • 1fdc0b08ad6afe61bbc2f054b205b2aab8416c48d87f2dcebb2073a8d92caf8d exe
    • afd98dde72881d6716270eb13b3fdad2d2863db110fc2b314424b88d85cd8e79 exe
  • Cert:
-----BEGIN CERTIFICATE-----
MIID3zCCAsegAwIBAgIJAK4RHChf5QoWMA0GCSqGSIb3DQEBCwUAMIGFMQswCQYD
VQQGEwJSVTEMMAoGA1UECAwDU1BiMQwwCgYDVQQHDANTUGIxGDAWBgNVBAoMD0ds
b2JhbCBTZWN1cml0eTEWMBQGA1UECwwNSVQgRGVwYXJ0bWVudDEZMBcGA1UEAwwQ
dGVzdC5kbW9zay5sb2NhbDENMAsGA1UEAwwEdGVzdDAeFw0xODA2MDUxNTIyMjBa
Fw0yMjA2MDUxNTIyMjBaMIGFMQswCQYDVQQGEwJSVTEMMAoGA1UECAwDU1BiMQww
CgYDVQQHDANTUGIxGDAWBgNVBAoMD0dsb2JhbCBTZWN1cml0eTEWMBQGA1UECwwN
SVQgRGVwYXJ0bWVudDEZMBcGA1UEAwwQdGVzdC5kbW9zay5sb2NhbDENMAsGA1UE
AwwEdGVzdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMua+rsContr
RIvQHX/M2qE4H30dIaLpYUqKll3GaZl8nkSxDAtyytfkMxiMeyn6tg2wy1M8RgGN
7dqtQwUJHfRdiaebmliKMPJHBn3SOhTd/caf7v552C85AQuOKZMWgaJ/3gQodmgI
Tr7p8q7g2OWg4nE0nGXXasFZYVEU3S81Z0wxNriRD9geNfkamv8fi0hm8HzDnLdi
bjvbTAsqTdegkkk/41ssXttckQRhRpgIzqRJ+sappdu4FzTuxOVA4jSRgZokD1l2
QFr4YTEJSUz4QHDGbow3nLvqTEHpvG90tgr+AHcR31otPiI1wm6bTj6IdicFENfC
4+5aIkvm72cCAwEAAaNQME4wHQYDVR0OBBYEFBIc9X32dzRzR9T1pmrmdZtshmJ9
MB8GA1UdIwQYMBaAFBIc9X32dzRzR9T1pmrmdZtshmJ9MAwGA1UdEwQFMAMBAf8w
DQYJKoZIhvcNAQELBQADggEBAE8AE11sWLICXcBO64iYByM96ZSWWN1JYGRaFWJ8
l8J1BiQNxh5N31X1HBs/sc87CPuqBB8CKxukoYU1T54HZQYmb3NHdc3JLFH2ah/o
028TSCXy16uvGGcxMhNcoZUCjWQHJzbXbVvPjkKjkJ1RR8DV1hRMcYLfO6LtSjAd
h7VnPVBNffGC/n9eTQjvwOR+dRN1IFLzwmpnwqVcxxjJM3+2OExfWBzKQ08/7MK/
xM8X8cmAb11Oyg7RXnE7X9Cfygy/Rz2fDGv4K7N8YDdL5osnyrN5fG8L2GG+srJ2
wdFYILlV+eLyfhwr6Oor5Z4zPgvcLLKbpHxQBvdkEdqX5F0= 
-----END CERTIFICATE-----

Sunday, May 27, 2018

MalHide: an interesting Malware sample

Today I'd like to share an interesting (at least to me) analysis on a given sample. I have called this sample MalHide but you will see "why" only at the end of my post :D. I believe this is a quite interesting Malware since it firstly implements several obfuscation stages by using different obfuscation techniques and secondly it implements a quite new attack path (not new per-se but new on opportunistic malware families) where the attacker doesn't want to steal informations and/or compromise a system for possession and/or destruction but the attacker uses the compromised system as eMail relay in order to hide the attacker networks. It is amazing to figure out that attackers are primary moving on fraud direction. For example, having a successful privilege access on the victim machine, the attacker might decide to performa several malicious actions, but among all the choices, he decides to spawn a SMTP relay to send anonymously fraud emails. Based on my past experience this is quite wired, isn't it ?!

Disclaimer: I'm not going into details on every steps since I'am not writing a tutorial but mostly I'd like to prove that threats are getting more and more complex on relative short time and that attack path is quite unique at least for my personal experience.

Everything started from an eMail attachment. "Nuovo Documento.doc" is its name and it is able to bypass every single AntiSpam and AntiMalware engine the target had. The following image shows the initial stage where the ".DOC" file seems to be benign but not compatible with the running Microsoft Word instance.

Sample as it looks like on opening. Stage 1

The sample presents some macro functions on it. Many junk functions have been injected on the VBA side in order to make life harder to reverse engineers, bu fortunately the great Microsoft VBA Editor included in the Microsoft Office suite implements an useful debugger. The analyst observes that the AutoOpen() function is preserved and filled by code. It took almost 3 seconds to figure out it was a malicious code. The following image shows the Microsoft VBA Editor debugging view where  is possible to appreciate the variable qZbTUw containing a PwerShell encoded code. Here we are ! The second stage is approaching to the victim.

Stage 2. A running instance of PowerShell invoked by VBA

The PowerShell code was Base64 Encoded and additionally obfuscated through "variable mess". This technique is quite common for  javascript devs since the code they develop runs on client side and obfuscating code is used technique to protect (sort of) the written code, but on the given scenario it looks like a simple implementation of FileLess Staging, where the attacker runs a powershell script directly from memory without saving it on HD, in such a way the victim does not need to enable the "running powershell from file" Microsoft register key and it's much harder from AntiVirus detect the infection stage. Then the script  fires it on following the infection. Powershell ISE helps us to reverse the dropped payload. The following images show the decoding process: from the single line of obfuscated code to dropping URLs. I know, it's almost impossible to see the images since they looks like small, but please click on them to make a bigger view,  if you wish.

Stage 3. Decoding Powershell Drop-and-Execute


Stage 3. Decoded Powershell Drop-and-Execute
The analyst is now able to identify the dropping websites and block them (please refer to IoC section) ! The executed actions are quite standard. From an array of dropping website lets cycle over them and take the one who drops ! The cycling policy could differ from sample to sample since they could use a pseudo-random seed generator or adopting an increment rotation or a round robin rotation and son. For this analysis is not interesting cycling policy at all since we decoded all the possible dropping files. The Powershell command gets the 52887.exe from external source (dropping websites) and places it on C:\Users\Public\52887.exe. Finally it runs it. The Stage 4 is began, a new PE sample has been executed. The following image shows the Stage 4 dropping another stage into C:\Windows\SysWOW64\fonduewwa.exe. Fortunately this stage drops the code from itself without getting on network side. The fonduewwa.exe is then executed.

Stage 4. 52887.exe dropping to C:\Windows\SysWOW64\fonduewwa.exe

The new stage (Stage 4) performs the following steps:

1) It fires up services which acts as SMTP client.
2) Connects to a Command and Control which provides emails addresses, SMTP relays, and eMails body to be sent.
3) Sends eMail to exploit BeC communications.

The following images show the Command and Control address. The first image shows the used Windows API while the second one addresses the opened connections directly on the infected machine.

Command and Control IP Address (click to make it bigger)

Command and Control DNS resolution (click to make it bigger)


The Command and Control (c2) listens to: c-67-176-238-209.hsd1.il.comcast.net which today resolves in: 67.176.238.209. The C2 seems to answers to http queries having a specific set of cookies as the following image shows. The C2 crafted and rebuilt communication, made possible by reconstructing cookies from sniffed internal communications, gets back from C2 a kB of encoded data.

Command and Control Communication through HTTP

From C2 comes actions, victims addresses, SMTP servers and passwords. The sample connects to a given SMTP relays, it authenticate itself and sends email to the victims. The following images proves that the attackers have plenty credentials to SMTP relays around the globe.

Connection to real SMTP releys

As now I will not disclose Username e Password for getting access to SMTP relays, but if you can prove to be the owner (or at least to be working for the company owning) of one of them let's have a chat on that, many interesting things are happening into your network. The emails sent from the analysed sample are targeting specific victims. It was pretty easy to figure out that we were facing a new attack vector! This attack vector looks like a BeC (or CEO Scam) to specific targets. For those of you not familiar with this attack I am copying the definition provided by SANS (here).
"Cyber criminals have developed a new attack called CEO Fraud, also known as Business Email Compromise (BEC). In these attacks, a cyber criminal pretends to be a CEO or other senior executive from your organization. The criminals send an email to staff members like yourself that try to trick you into doing something you should not do. These types of attacks are extremely effective because the cyber criminals do their research. They search your organization’s website for information, such as where it is located, who your executives are, and other organizations you work with. The cyber criminals then learn everything they can about your coworkers on sites like LinkedIn, Facebook, or Twitter. Once they know your organization’s structure, they begin to research and target specific employees. They pick their targets based on their specific goals. If the cyber criminals are looking for money, they may target staff in the accounts payable department. If they are looking for tax information, they may target human resources. If they want access to database servers, they could target someone in IT.Once they determine what they want and whom they will target, they begin crafting their attack. Most often, they use spear phishing. Phishing is when an attacker sends an email to millions of people with the goal of tricking them into doing something, for example, opening an infected attachment or visiting a malicious website. Spear phishing is similar to phishing; however, instead of sending a generic email to millions of people, they send a custom email targeting a very  small, select number of people. These spear phishing emails are extremely realistic looking and hard to detect. They often appear to come from someone you know or work with, such as a fellow employee or perhaps even your boss. The emails may use the same jargon your coworkers use; they may use your organization’s logo or even the official signature of an executive. These emails often create a tremendous sense of urgency, demanding you take immediate action and not tell anyone."

Following few examples of the sent emails coming from C2 and delivering through the analysed sample.


Here we are, another email has been sent, another Malware have been thought and developed, another analysis I've been made but this time it looks like the "Malware economy" is seriously moving to fraud, there is much money respect to information stealing which is an ancient and romantic way to attack victims. Is this attack a significative example expressing the will of the new underground economy ? Is this attack a small and silent change of paradigm, where previously the attacker was interested to your data in order to sell them but now he gets more interested on fraud third parties (such as companies) through you ? I do not have such answer here.

Ok, now it's time to explain why I called this Malware MalHide. Well it's a complex Malware, it hides itself several times BUT most important it has been developed to hide the attacker from sending emails in a way that is not possible to trace back the Attacker IP from the attack path. So I believe MalHide would be a nice name :D

IoCs:

Samples:

  • 2f1f03b4afde643b2ed798e62f4718b0a285b8a8
  • e6b1a4b09613f1729782f1b2c04a30ad5ff30200
  • da39a3ee5e6b4b0d3255bfef95601890afd80709
Dropping URLs:
  • http://oddbods.co.uk/D6yd9x/
  • http://136.243.206.64
  • http://166.63.0.27
  •  http://136.243.206.64
  • http://promoclass.it/ACCOUNT/Invoice-161021407-Invoice-date-052518-Order-no=-06146166318/
Local Path:
  • C:\Windows\SysWOW64\fonduewwa.exe
  • C:\Users\Public\52887.exe
C2:
  • 67.176.238.209
  • c-67-176-238-209.hsd1.il.comcast.net
SMTP (contacted to send eMails, those are not malicious per-se !):
  • 186.1.11.125 (smtp.echamorro.com.ni)
  • 192.243.105.21 (mail.mcmillins.com)
  • 209.91.128.17 (mail.maslack.com)
  • 64.8.70.103 (mail.tds.net)
  • 208.80.38.254 (pop.spiderhost.com)
  • 193.252.22.84 (smtp.orange.fr)
  • 199.103.57.167 (mail.mytravelclinic.com)
  • 149.115.16.7 (mail.transamericanengineers.com)
  • 68.99.120.8 (mail.coxmail.com)
  • 74.125.71.108 (smtp.gmail.com)
  • 76.12.209.196 (mail.gachivvis.com)
  • 107.14.166.78 (pop.biz.rr.com)
  • 64.39.128.67 (mail.syrupcity.net)
  • 107.180.3.218 (mail.rutledge-associates.com)
  • 165.212.120.200 (exchange.postoffice.net)
  • 64.35.208.130 (smtp.atcnet.net)
  • 207.204.50.27 (mail.cabstore.biz)
  • 216.52.72.118 (smtp.zoho.com)
  • 209.237.135.167 (mail.astarabatement.com)
  • 107.14.166.72 (smtp.twcny.rr.com)
  • 74.208.5.2 (smtp.1and1.com)
  • 209.123.49.115 (ssl.datamotion.com)
  • 208.92.193.92 (mail.hdap.ca)
  • 68.178.213.37 (smtp.secureserver.net)
  • 72.167.238.29 (smtp.secureserver.net)
  • 66.226.70.67 (pop.doubleolaser.com)
  • 205.178.146.249 (mail.boersmatravel.com)
  • 173.201.192.229 (smtpout.secureserver.net)
  • 64.59.128.135 (mail.shaw.ca)
  • 69.156.240.33 (mail.bestelectric.ca)
  • 38.123.104.66 (smtp.263.net)
  • 184.106.54.11 (smtp.emailsrvr.com)
  • 184.106.54.10 (secure.emailsrvr.com)
  • 209.237.135.166 (webmail5.myregisteredsite.com)
  • 74.125.133.16 (pop.googlemail.com)
  • 68.178.252.229 (smtpout.secureserver.net)
  • 64.20.48.173 (mail.expertforccna.com)
  • 72.47.216.15 (smtp.newalbanyelitedental.com)
  • 66.102.1.109 (pop.gmail.com)
  • 205.207.122.80 (mail.connection.ca)
  • 182.50.145.3 (smtpout.asia.secureserver.net)
  • 74.125.133.109 (imap.gmail.com)
  • 74.6.141.48 (smtp.att.yahoo.com)
  • 193.252.22.86 (smtp.orange.fr)
  • 68.178.252.101 (smtpout.secureserver.net)
  • 69.4.62.69 (pop.kerrcad.org)
  • 69.168.106.36 (smtp.windstream.net)
  • 188.125.73.26 (smtp.mail.yahoo.com)
  • 65.254.254.53 (mail.fatcow.com)
  • 65.254.254.52 (mail.fatcow.com)
  • 69.49.123.241 (mail.salzburginteriors.com)
  • 207.29.219.108 (mail.bayou.com)
  • 198.57.169.26 (bst-hosting.com)
  • 207.223.121.25 (mail.cloudopscenter.com)
  • 207.204.50.18 (mail.reliusmed.com)
  • 208.180.150.85 (mail.lrgriffin.com)
  • 217.15.86.61 (mail.roche-bobois.com)
  • 204.8.72.128 (mail.gdins.org)
  • 66.96.160.206 (pop.seriousfunnyc.org)
  • 66.175.58.40 (mail.mhpwq.org)
  • 207.204.50.11 (mail.prestonequipment.com)
  • 208.89.138.22 (m.ivenue.com)
  • 205.178.146.235 (mail.holstongases.com)
  • 68.15.34.125 (mail.jancompanies.com)
  • 212.82.101.35 (smtp.verizon.net)
  • 192.185.4.163 (gator4151.hostgator.com)
  • 137.118.58.15 (pop.totelcsi.com)
  • 207.69.189.23 (smtp.ix.netcom.com)
  • 68.87.20.6 (smtp.comcast.net)
  • 65.254.250.110 (smtp.franklintonnc.us)
  • 66.118.64.100 (smtp.citynet.net)
  • 173.203.187.10 (pop.emailsrvr.com)
  • 173.15.144.57 (mail.pembertonpolice.com)
  • 173.203.187.14 (mail.sbctransportation.com)
  • 72.52.250.187 (www11.qth.com)
  • 68.178.213.203 (smtp.secureserver.net)
  • 64.78.61.107 (mail16.intermedia.net)
  • 165.212.11.125 (smtp.postoffice.net)
  • 72.35.23.61 (pop.callta.com)
  • 206.188.198.65 (mail.bayoubendtx.com)
  • 65.254.250.100 (pop.powweb.com)
  • 64.29.151.235 (mail.arizoncompanies.com)
Used eMails (sender):
  • helene.valeze@wanadoo.fr
  • mehdi.audam@wanadoo.fr
  • dominique.derbord@wanadoo.fr

Sunday, March 25, 2018

CERTs, CSIRTs and SOCs after 10 years from definitions

Nowadays is hard to give strong definitions on what are the differences between Security Operation Centers (SOC), Computer Emergency Response Teams (CERT) and Computer Security Incident Response Teams (CSIRT) since they are widely used in many organisations accomplishing very closed and similar tasks. Robin Ruefle (2007) on her paper titled "Defining Computer Security Incident Response Teams" (Available here) gave us a nice idea. She also admits (at the end of the paper) there is not such a strong difference between those common terms: CSIRT, CERT, CSIRC, CIRT, IHT. Her conclusion made me thinking about how this topic has been evolving over the past 10 years.  

Despite her amazing work on defining (let me call) CSIRTs I would give you more details on how those teams have been evolving over the past decade based on my personal experiences directly to the field. Indeed after being involved on building several CERTs, organising CSIRTs and evaluating SOCs I started to spot strong and soft similarities between those teams. Today I'd like to share with you those strong and soft similarities without talking about "differences" since there are not evidence on differences at all.

Each team is asked for CyberSecurity incidents but each team holds specific aims and respond to cybersecurity incident in a specific way. Every team needs to understand what happened after a cybersecurity related incident and this is the very strong common point that every team takes care of: deeply understand what happened. Nobody is better then other or nobody is more addicted respect to other in understanding what really happened during an incident, every team have fully autonomy to figure out what happened through inspection and analytical skills.  The weak similarities come after the initial understanding (analysis) phase. CSIR Teams ad SOC Teams usually study the related incident looking for a response while CERT usually tries to forecast incidents. The definition of response highlight the "weak similarities" between CSIRT and SOC. 

CSIRT usually (but not necessary) look to the incident with a "business" perspective taking care of (but not limited to): communication countermeasures, policy creations, insurance calls, business impact analysis, technical skillset and off course taking care about technical mitigations. For example a CSIRT would evaluate according to the marketing area a communication strategy after a successful incident hit the company, or it could call insurances to evaluate if they will cover some damages or again it could interact to HR area to define missing skillsets in the organisation. Off course it is able to interact with defensive technologies but it's only one ste of its tasks.

A SOC usually (but not necessary) look to the incident with a more "technical" perspective taking care of (but not limited to): incident forensic, log analysis, vendor calls, patch distributions, vulnerability management and software/hardware tunings.  For example after an incident happened to an organisation its SOC would try to block it involving all its resources to block the threat by acting on peripheral devices or running commands directly on user's machines. The SOC deeply understands SIEM technology and it is able to improve it, it is also able to use and to interact through defensive teams and/or technology like sandboxes, proxy, WAF as well. The SOC team holds strong network oriented capabilities.

CER Teams usually take care about incidents following the community sharing procedures such as (but not limited to): feeds, bulletin, Index of Compromises and applying effective governance actions to local IT/SOC teams enabling them to mitigate the incident in the fastest way possibile. CERT team members work a lot with global incidents understanding new threats and tracking known threat movements. They usually work with Threat Intelligence Platforms and with high level dashboard to better understand the evolution of threats to forecast new attacks.

CERTs and SOCs are usually focused on prevention such as (but not limited to): what are the best rules to apply ? What are the procedures in case of incidents ? They are really focused on using threat intelligence in order to spot attack and to block incidents. On the other hand CERTs and CSIRTs are mostly focused on Guidelines and business impact analysis while SOCs and CSIRTs really need to follow incident response procedures in order to apply their high technical skills to mitigate the attack. The following image tries to highlight the main (but not the only) keywords that you would probably deal if you work on a SOC a CERT or in a CSIRT.




The main ideas (but not the only ones) behind the 3 teams could be summed up in the following terms: Mitigation (belongs to SOC), Response (belongs to CSIRT) and Alerting-Prevention (belongs to CERT). I'd like to point out that mitigation and response are quite different concepts. Indeed mitigation holds a technical view of the resolution, response holds a more business view of the resolution. While mitigating an incident means to "take it down" and so to restore the attacked system as it was before the incident, an incident response could include more sophisticated actions that could include the board of director in the decision process as well.
   
Similar teams but with strong attitudes need different professional profiles. Usually (but again not necessary) SOC Teams need more technical profiles which includes hard skills such as: vendor based certifications, network oriented attitudes and forensic attitudes. CSIRT teams needs a mixup profiles more oriented to technical skills but also with business view such as: risk evaluation, guideline buildings and communication skills. CERTs need to have a wide landscape vision about threats and for such a reason they need to know threat intelligence, they need to know prevention tools and to be part of strong IoC sharing communities. Developer skills are not mandatory on those teams but if "weak and dirty" scripting skills are in place, the entire team will benefit from them. Automation and integration are widely needed on such a teams and a scripting profile would create such an integrations.

As mentioned at the beginning of this "post" it is hard ...  almost impossible ... to give hard definitions about the evolution of "CSIRTs" but it's possible to observe strong and weak similarities in order to better understand what team is most suitable for every organisation.  If you belongs to a "CSIRT" or to a "SOC" or to a "CERT" and you feel like you are doing a little bit of each team according to my post, well, it is ok ! In ten years "things" have been changed a lot from the original definitions  and it's quite normal being involved in hybrid teams.

Wednesday, February 21, 2018

Control Flow Integrity: a Javascript Evasion Technique

Understanding the real code behind a Malware is a great opportunity for Malware analysts, it would increase the chances to understand what the sample really does. Unfortunately it is not always possible figuring out the "real code", sometimes the Malware analyst needs to use tools like disassemblers or debuggers in order to guess the real Malware actions. However when the Sample is implemented by "interpreted code" such as (but not limited to): Java, Javascript, VBS and .NET there are several ways to get a closed look to the "code”.

Unfortunately attackers know what the analysis techniques are and often they implement evasive actions in order to reduce the analyst understanding or to make the overall analysis harder and harder. An evasive technique could be implemented to detect if the code runs over a VM or it could be implemented in order to run the code only on given environments or it could be implemented to avoid debugging connectors or again to evade reverse-engineering operations such as de-obfuscations techniques. Today "post" is about that, I'd like to focus my readers attention on a fun and innovative way to evade reverse-engineering techniques based on Javascript technology.

Javascript is getting day-by-day more important in term of attack vector, it is often used as a dropper stage and its implementation is widely influenced by many flavours and coding styles but as a bottom line, almost every Javascript Malware is obfuscated. The following image shows an example of obfuscated javascript payload (taken from one analysis of mine).

Example: Obfuscated Javascript


As a first step the Malware analyst would try to de-obfuscate such a code by getting into it. Starting from simple "cut and paste" to more powerful "substitution scripts" the analyst would try to rename functions and variables in order to split complexity and to make clear what code sections do. But in Javascript there is a nice way to get the callee function name which could be used to understand if a function name changed over the time. That function is the arguments.callee.caller. By using that function the attacker can create a stack trace where it saves the executed function chaining name list. The attacker would grab function names and use them as the key to dynamically decrypt specific and crafted Javascript code. Using this technique the Attacker would have an implicit control flow integrity because if a function is renamed or if the function order is slightly different from the designed one, the resulting "hash" would be different. If the hash is different the generated key would be different as well and it wont be able to decrypt and to launch specific encrypted code.

But lets take a closer look to what I meant. The following snip shows a clear (not obfuscated) example explaining this technique. I decided to show not obfuscated code up here just to make it simple.



Each internal stage evaluates ( eval() ) a content. On row 21 and 25 the function cow001 and pyth001 evaluates xor decrypted contents. The xor_decrypt function takes two arguments: decoding_key and the payload to be decrypted. Each internal stage function uses as decryption key the name of callee by using the arguments.callee.name function. If the function name is the "designed one" (the one that the attacker used to encrypt the payload) the encrypted content would be executed with no exceptions. On the other side if the function name is renamed (by meaning has been changed by the analyst for his convenience) the evaluation function would fail and potentially the attacker could trigger a different code path (by using a simple try and catch statement). 

Before launching the Sample in the wild the attacker needs to prepare the "attack path" by developing the malicious Javascript and by obfuscating it. Once the obfuscation took place the attacker needs to use an additional script (such as the following one) to encrypt the payloads according to the obfuscated function names and to replace the newly encrypted payload to the final and encrypted Javascipt file replacing the encrypted payloads with the one encrypted having as a key the encrypted function names.

The attacker is now able to write a Javascript code owning its own control flow. If the attacker iterates such a concept over and over again,  he would block or control the code execution by hitting a complete reverse-engineering evasion technique.
  
Watch it out and be safe !

Saturday, January 20, 2018

Huge Botnet Attacking Italian Companies

On January 18 a colleague of mine (Luca) called me telling a malicious email was targeting Italian companies. This is the beginning of our new analysis adventure that Luca and I run together.

The email pretended to be sent by "Ministero dell' Economia e delle Finanze" the Italian Department of Treasury  and it had a smart subjects such as:
    • Codici Tributo Acconti
    • F24 Acconti-Codice Tributo 4034
The attacker knows very well the Italian Fiscal Year since those modules are very popular from company administration employees at that time. The attacker would probably exploit this attack path reaching out as many companies as possible. The email address was not coming from the "Ministero dell' economia e delle Finanze" at all, it was coming from the following addresses:
    • info@amber-kate.com
    • info@fallriverproductions.com
The email looks like :

Malicious eMail

A simple link pointing to a high reputation domain was popping out the default browser and downloading the following Javascript file. The high level of obfuscation and the way the content was provided was so suspicious to be worth to follow the analysis.

Infection: Stage 1 Obfuscated

After a deobfuscation phase the javascript looked much more easy te be read from a human side.

Infection: Stage 1 Clear Text
A romantic "drop and execute" section was happening. A GET connection to 239outdoors.com/themes5.php was dropping a file named 1t.exe and later on the same script was able to execute the dropped file.  The file 1t.exe was running on the victim machine contacting the Command and Control waiting for further commands.

The new sample looks like GootKit, a weaponized version of Banker Malware.  The malware installs itself and contacts Command and Control asking "what to do" and sending the "stolen credentials" directly to the Command and Control server. Details on IPs, Persistencies and so on, is provided in the IoC section, but todays we wont describe GootKit, we got access to the Dropping site !  

We want to figure out if we might help victims to deactivate the malicious botnet by providing as much as possible details without focusing on reverse the Malware per se since appears to be known. 

By getting further analyzing the dropping web site we immediately understood that the same URL was dropping another threat. The parallel threat the dropping website was spreading to the world was called "Nuovo Documento 2008" and it was a .bat file as follows.

New Threat Stage 1

That executable .bat file on a first stage opens up a browser pointing to a legitimate image but later on it uses an notorious technique called "certutil for delivery of file" to drop and execute an another file. This technique is well described here  by carnal0wnage. Basically the attacker uses the certutil.exe program do download a Base64 encoded payload, to decoded it and to run it. This technique is very silent since the User-Agent of certutils.exe is not suspicious because it needs to connect outside the company networks to check certificates, so not much IPS rules on it. The dropped file name unslss.exe appears to be very close to the previous analyzed one (1t.exe) it contacts the same C&C and it behaves in the similar way.   But again we wont focus on reverse such a malware but rather we wont be able to reach the highest number of IoC to protect as much as possible the victims. By analyzing the Dropping website we founded that a significative number of connections had additional referrers, so we decided to focus our attention on how many DNS were pointing to such a domain. We did it and the result was quite impressive (please see the Dropping URLS IoC Section). 

Following the research on the dropping website we found an interesting log within all the connection coming from possible victims. We collected that log, and we built the following possible infection list (possible Victims). We wont publish the Victims IP addresses but if you can prove you are legitimated by your company to ask that logs we can give you (for free, of course)  the IP addresses we've found related to your company. Please contact cert@yoroi.company. A detailed list of possible infected networks follows. 

Possible Victims:









  • ACI informatica s.p.a.

    • AGOS-AS
    • AGSM Verona Spa
    • ASGARR Consortium GARR
    • Acantho S.p.a
    • Alfanews S.r.l.
    • Ambrogio s.r.l.
    • Asco TLC S.p.A.
    • Autostrade-as
    • BT Italia
    • BT Italia S.p.A.
    • Banca Monte Dei Paschi Di Siena S.P.A.
    • Brennercom S.p.A.
    • COLT Technology Services Group Limited
    • Camera dei deputati
    • Cesena Net srl
    • Clouditalia Telecomunicazioni S.p.A.
    • Comune Di Brescia
    • Comune di Bologna
    • Consortium GARR
    • Consorzio per il Sistema Informativo
    • Costacrociere-as
    • Duebite-as
    • E4A s.r.l.
    • Energente S.r.l.
    • FASTNET SpA
    • FASTWEB SPA
    • FINECO Banca del Gruppo Unicredit
    • Fastweb
    • Forcepoint Cloud Ltd
    • GenyCommunications
    • Global Com Basilicata s.r.l.
    • H3G Italy
    • Hynet S.R.L.
    • IBSNAZ
    • ICT Valle Umbra s.r.l.
    • InAsset S.r.l.
    • InfoCamere SCpA
    • Infracom Italia S.p.A.
    • Inrete s.r.l
    • Insiel- Informatica per il sistema degli enti loca
    • Integrys.it di Stefania Peragna impresa individual
    • Intred S.p.A.
    • KPNQWest Italia S.p.a.
    • LEPIDA
    • Lepida S.p.A.
    • Liguria Digitale S.C.p.A.
    • Linea Com S R L
    • Linkem spa
    • Lombardia Informatica S.p.A.
    • Mandarin S.p.A.
    • Mc-link SpA
    • Metrolink S.R.L.
    • Ministero dell'Interno
    • Mnet srl
    • NGI SpA
    • Nemo S.r.l.
    • Nordcom S.p.a.
    • Officine Informatiche Srl
    • Progetto Evo S.r.l.
    • Provincia di Reggio nell'Emilia
    • Qcom spa
    • Raiffeisen OnLine GmbH
    • Regione Basilicata
    • Regione Toscana
    • Regione Veneto
    • STI ADSL
    • Sardegnait-as
    • Societa' Gestione Servizi Bp S.p.A.
    • TELEX S.r.l.
    • TWT S.p.A.
    • Telecom Italia
    • Terra S.p.a.
    • Time-net S.r.l.
    • Tiscali SpA
    • Trenitalia SpA
    • Trentino Network S.r.l.
    • Universita' degli Studi di Milano
    • Venis S.p.A.
    • Videotime SPA
    • Vodafone Group Services GmbH
    • Vodafone Italia DSL
    • Vodafone Omnitel B.V.
    • Vodafone Omnitel N.v.
    • WIIT S.p.A.
    • Welcome Italia S.p.A
    • Wind Telecomunicazioni
    • Wind Telecomunicazioni SpA
    Following the found IoC provided by the long "analysis journey". I managed this analysis over the night, so I am sure there would be some imprecisions, but I preferred to speed up the entire analysis process to give the opportunity to block such infamous threat as soon as possible.

    Hope it helps the community.

    Original Early Warning (Italian): Yoroi Early Warning



    IoC:

    • eMail:
      • info@amber-kate.com
      • info@fallriverproductions.com
    • Dropping URLS:
      • 185.61.152.71
      • 239outdoors.com
      • bentlabel.com
      • cdvdautomator.com
      • cloudblueprintprogram.com
      • cnchalftone.com
      • comedyyall.com
      • conticellolaw.com
      • couplesdoingbusiness.com
      • dvoper.com
      • equinnex.com
      • ericandchrissy.com
      • evelynleekley.com
      • expungementstennessee.com
      • flaveme.com
      • grkisland.com
      • healingfoodconsulting.com
      • hertzsynergy.com
      • hollywoodisruption.com
      • home-sphere.com
      • integrativenutritiontherapy.com
      • jdkanyuk.com
      • kineloveclips.com
      • kylesinger.com
      • legionchristmas.com
      • menshoesonlinestore.com
      • microtiasurgery.com
      • movielotbar.com
      • muiienweg.com
      • niarhoslondon.com
      • opsantorinitours.com
      • progunjobs.com
      • rocketpak.com
      • scottishwindowsolutions.com
      • silkygames.com
      • snapshotsandwhatnots.com
      • snotterkind.com
      • solespin.com
      • strangerthanchristmas.com
      • synchronr.com
      • taramadden.com
      • terento.website
      • theargumint.com
      • thegildedwren.com
      • thejourneytogodsheart.com
      • thesaltybody.com
      • topsantorinitours.com
      • tuftandneedles.com
      • videospanishlessons.com
      • vovachka.com
      • wall-runners.com
      • war-arena.com
      • www.scottishwindowsolutions.com
      • z1logistics.com
      • zayantetinyhomes.com
      • zefeed.com
    • Command and Controls
      • 185.44.105.97 
      • ns15.dreamsinthesun.com
      • bdi2.nomadicdecorator.com
      • elis.k9redemptionrescue.com
      • api.hailstorm360.com
      • cerera.survivalbid.com
      • mark.k9redemptionrescue.org
      • nsc.dayswithsunrays.com
      • at.moonbeammagic.com
      • ssl.vci-cfo.com
      • sip3.propertiesandprojects.com
      • host1.jodiray.com
      • note.lawrencechoy.com
      • note.lawrencechoy.com:80
      • 185.44.105.97:80/200
      • note.lawrencechoy.com:80
    • Hashes
      • 63d6927881d4978da4e162c17d82e9c009d0a93e
      • 7ea33f51b6c4aa54beee7fd878886339c22d2232
      • 8cae0dc9255978a35cfd8db64cbe80001400de9b
      • 839ff9f4c3980ac67d4cbef296520ee364a0911f
      • 8cae0dc9255978a35cfd8db64cbe80001400de9b



    UPDATE 1:

    Many AV and NGFirewall Companies contacted me and they updated "signatures", so probably on from now everybody having such a products should be protected.

    UPDATE 2:

    Victims are still growing UP !

  •  Asco TLC S.p.A.
  •  ASGARR Consortium GARR
  •  Bancalombarda
  •  B.B.Bell SPA
  •  Brennercom S.p.A.
  •  BrianTel SRL
  •  Consiglio Nazionale delle Ricerche
  •  Elsynet S.r.l.
  •  Fastcon-as
  •  Informatica System S.r.l.
  •  Inrete s.r.l
  •  IPERV Internet Per Il Veneto
  •  I.S.I.D.E. S.p.A.
  •  Mc-link SpA
  •  Nemo S.r.l.
  •  NTRNET SRL
  •  Regione Autonoma Friuli Venezia Giulia
  •  Tiscali SpA
  •  UmbriaNet
  •  Universita' degli Studi di Palermo
  •  AGOS-AS
  •  Comune di Bologna
  •  ENEA - Agenzia nazionale per le nuove tecnologie
  •  Intred S.p.A.
  •  Iren Energia S.p.a
  •  Linkem spa
  •  NGI SpA
  •  Phoenix Informatica Bancaria S.p.A.
  •  Telemar s.p.a.
  •  TWT S.p.A.
  •  Wiplanet.it
  •  COLT Technology Services Group Limited
  •  Consortium GARR
  •  H3G Italy
  •  Banca Monte Dei Paschi Di Siena S.P.A.
  •  BT Italia S.p.A.
  •  Infracom Italia S.p.A.
  •  KPNQWest Italia S.p.a.
  •  Vodafone Omnitel B.V.
  •  Liguria Digitale S.C.p.A.
  •  Regione Toscana
  •  Welcome Italia S.p.A
  •  Wind Telecomunicazioni
  •  Lepida S.p.A.
  •  Vodafone Italia DSL
  •  Fastweb
  •  Telecom Italia



  • Thursday, December 28, 2017

    Info Stealing: a new operation in the wild

    Attack attribution is always a very hard work. False Flags, Code Reuse and Spaghetti Code  makes impossible to assert "This attack belongs to X". Indeed nowadays makes more sense talking about Attribution Probability rather then Attribution by itself. "This attack belongs to X with 65% of attribution probability" it would be a correct sentence.

    I made this quick introduction because the following analysis would probably take the reader to think about specific attribution, but it wont be so accurate, so please be prepared to have not such a clear conclusions.

    Today I'd like to show an interesting analysis of a quite new InfoStealer Malware delivered by eMail to many International Companies. The analysis shows up interesting Code Reuse capabilities, apparently originated by Japanese Attackers reusing an English Speaker Attacker source code. Again I have not enough artifacts to give attributions but only few clues as follows. In the described analysis, the original sample was delivered by sarah@labaire.co.za (with high probability a compromised South Africa account) to one of my spamming email addresses.

    The obtained sample is a Microsoft Word document within macro in it. The macros were heavily obfuscated by using four rounds of substitutions and UTF-8 encoding charsets (which, by the way, is super annoying). The following image shows the obfuscated macro code with UTF-8 charsets.

    Stage 1: Obfuscation
     By using oletools and "tons" of cups of coffee (to be awake until late night to make recursive steps) I finally was able to extract the invoked command, showed in the following image.

    Stage 1: Invoked Command
    A fashionable powershell command drops and executes: hxxp://ssrdevelopments.co.za/a2/off.exe. Powershell seems to be a "must have" in contemporary Malware. Analyzing the "dropping" url and tracking down the time it is in "Index Of" mode (2017-0-13), I suspect it is not a compromised website rather a crafted web server or a compromised host of a dead company.

    Dropping Web Site

    By surfing on the Malware propagator web site I founded out many malicious executables (sees IoC section) each one showing up specific behaviors such as: password stealers, RAT and Banking Trojans. Even if the samples were developed for different targets, all of them shared the following basic behaviors:

    • Check for victims IP address before getting into Malicious activities (maybe related to targeted activities)
    • Install itself into auto execution path
    • Tries to fingerprint the target system (such as CPU, HD, Memory, Username, System, etc..)
    • Sniff for Keystrokes

    I'd like to write a simple analysis for each found sample, but today time is not my friend, so let's focalize to one of the malicious samples. Let's get done the received sample by digging into the "second stage" dropped by the powershell "first stage" from ssrdevelopments.co.za/a2/off.exe. After few seconds on second stage (off.exe) it became clear that it was a .NET software. By reversing the interpreted .NET language some clear text comments appeared interesting. Japanese language such as comments and variable names came out from static analysis. Let's have a look to them.

    Stage 2: Apparently Japanese characters

    While the sample pretends to be compiled from "Coca-Cola Enterprise" (maybe a target operation against Coca-Cola ? Or a targeted operation agains Coca-Cola Suppliers ? So why it ended up to my inbox ? Anyway ... ) google translator suggests me that Japanese characters are in text: such as the "Entry Point", "Class names" and "Function Names". 

    Stage 2: Japanese Names and Self Encoding Structures

    It was not hard to figure out that Stage 2 was auto-extracting bytes from itself (local variables) and saving them back to hard drive after having set up auto execution registry key on windows local registry.  The following image shows the xoring function used to decrypt converted bytes to the real payload. 


    Stage 2: Xoring function to extract Stage 3

    On my run, the xored payload took the name of GIL.exe; another .NET  executable. We are now facing the third stage. By analyzing the decompiled sample it became clear that:
    • The coding style was quite different from the previous stage (Stage 2)
    • The implementation style was different from the previous stage as well
    • The sample was interested on information about the user, the machine, the webservices on the PC and to many more windows specific parameters.
    Stage 3:  New Language in Strings and Class names
    Stage 3: New Code Style

    By closely investigating Stage 3, the analyst would probably notice the heavy presence of "decorators", a different format in the definition style and last but not least the code composition. Everything looks like belonging to different single developers. The variable language, the comments structure and the general usage of terms, takes the analyst to believe in having found two different developers belonging to different cultures (maybe countries). Finally the malware looks for users, computes, and webservices informations and drops everything up to C2 by posting parameters to : ssrdevelopments.co.za/cgi-bin/

    IoC:
    Following the principal IoC for the described threat.
    • Hash Stage 1:
      • 7f1860673de9b1c2e6f7d6963a499e8ba4e412a1
      • bf4a26c9e52a8cacc7afd7d95d197bff1e47fb00
    • Hash Stage 2:
      • ac55ee783f3ed0bd23eccd01040a128dc6dc7851
    • Hash Stage 3:
      • 6a38e4acd9ade0d85697d10683ec84fa0daed11c
    • Persistence: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\kij %APPDATA%\Roaming\kij\kij.exe
    • Dropping URL:
      • ssrdevelopments.co.za
    • Command and Control:
      • ssrdevelopments.co.za/cgi-bin/
    • Related hashes from harvesting Dropping URL:
      • 62c9d2ae7bafa9c594230c570b66ec2d4fa674a6
      • b15b69170994918621ceb33cb339149bdff5b065
      • 55abcfb85e664fbc8ad1cb8b60a08409c2d26caa
      • f843427e9b7890f056eaa9909a5103bba6ffb8fd
      • f2b81e66fcb1032238415b83b75b3fe8bf28247d
      • cab90f7c935d355172b0db123d20b6a7d1403f65
      • c1ba30d7adec6d545d5274f95943f787ad4c03e7
      • ed9959bb0087f2c985b603cee0e760f3e0faaab15
      • c93851627ffd996443f85d916f3dbedd70e0ff69
      • 144b34b4816062c2308a755273159e0460ffd604
      • 98293b80ccf312a8da99c2b5ca36656adebd0d0f 
      • 2875d1b54337b1c17c8f4cd5f6b2d579667ee3d9 
      • 0b4299ffb3f9aa59e19dd726e79d95365fe1d461
      • 46bb0b10d790a3f21867308e7dcdeb06784a1570
      • 0960726560a94fbbb327aa84244f9588a3c68be8 
      • a480a75c3af576e5656abadb47d11515a18a82be
      • 2ba809c53eda2a475b1353c34f87ce62b6496e16
      • 5b0c3071aa63e18aa91af59083223d3cceb0fa3c 
      • dc780bf338053e9c1b0fdf259c831eb8a2768169

    As final thought I'd like to highlight the following key concept of that analysis:
    • From a single email, the analyst could discover attacker's assets, mapping them and disarming them (through IoC). 
    • The analyzed code shows apparent evidences to belonging to different groups of attackers.
    • The analyzed samples show code reuse. Code reuse is dangerous because it makes attackers more powerful and extremely quick to change Malware behavior.
    Hope you enjoyed.