The security company ESET [1], in association with CERT-UA [2] has identified a variation of the Industroyer malware [3]. In contrast to the initial version, this sample seems to be created to target specific environments due to its use of hard-coded IP addresses and configuration parameters. It incorporated only the IEC-104 protocol as its preferred method of communication with the targeted devices. The overall functionality of the malware aims once again to perform actions against the electrical sector of Ukraine.
Analysis
The malware is created to target specific ICS devices that leverage the IEC 60870-5-104 protocol commonly found in the electrical sector [4]. This is the only protocol that is leveraged this time compared to the multitude of protocols that were accompanying the original version.
As seen in Figure 1, the malware has been compiled on March 23, 2022, at 04:07:29. This precedes the compilation of the sample that is detailed in the ESET report (March 23, 2022, 06:35:32). The sample also differs from the one reported by ESET in terms of the number of embedded configurations. The provided sample includes three configurations (Figure 2) while the one from ESET includes eight. That could indicate the compromise of multiple entities from the threat actor in order to achieve a greater effect. Industroyer2 can communicate with numerous devices by spanning multiple threads.
Figure 1: Basic information about the malware.Figure 2: The configuration strings embedded into the executable.
The malware provides two options to the user via the -t and -o parameters as seen in Figure 3. The former can be used to delay the execution of Industroyer2 while the latter allows to write the output in a log file (Figure 4).
Figure 3: The routines that perform the actions based on the CLI options and parameters.Figure 4: The output of Industroyer2 when the -o option is used.
It then proceeds with the parsing of the parameters from the hard-coded strings (Figure 5). We see that the stations’ IP addresses and the IEC-104 protocol port are defined in the configuration strings along with some IEC-104-specific information such as ASDU (Application Service Data Unit) address, Information Object Addresses (IOA) [4], and the actions that will be taken against the targeted devices as seen in Figure 6. Some of the fields of each configuration string that can be seen immediately are the ASDU (3,2,1), a predefined number of the IOA (44, 8, 16), each IOA (e.g., 130202, 1104, 1258), and an indicator of which IOA is executed (e.g, 1,2,3…44). Each configuration seems to follow the structure of the configuration file that was related to the Industroyer version of 2016.
Figure 5: The execution of the parsing of each configuration string.Figure 6: Some of the values in the hard-coded strings, used for the IEC-104 communication.
Once the parsing has finished, the malware attempts to terminate the processes that have its name hard-coded in the executable and rename a file provided in the configuration by adding the .MZ file extension to it (Figure 6). That could have been an attempt to make restoration of communications of the benign software with the devices more difficult as such a rename will prevent any task or service to re-launch it.
Figure 7: The termination of processes and renaming of the file using the .MZ extension.
Industroyer2 then moves one with the creation of sockets and connections with IP addresses from the configuration strings. Figure 7 illustrates the actions that are followed based on the IEC-104 protocol, enabling the malware to test, start and stop the transfer of data.
Figure 8: Some of the strings that indicate the actions taken by the malware.
The threat actor seems to be in the knowledge of the targeted environments as configurations include specific IOAs and actions that are performed by the malware. The state of each device based on the IOA can be set to either ON or OFF. Using an IEC-104 simulator provided by FreyrSCADA [5] allows us to see the actions and changes of the Industroyer2. Using a partial configuration of 4 IOAs that are embedded in the first configuration string (Figure 9), we see that when the malware is initiated the values of the IOA can be changed as it is illustrated in Figure 10.
Figure 9: The setup of four IOAs for demonstration purposes Notice that that last four, Single Point and Double Point, are used to monitor the changes made by Industroyer2.Figure 10: Monitoring of the changes made by Industroyer2.
An overview of the packet capture can be found in Figure 11. We can see that the testing and start of connections take place along with the issue of commands. We can also observe that the threat actor is in possession of specific information about the environment since if we do not provide some specific IOAs to the server simulator, the response will be an unknown IOA status (UkIOA in Figure 12), something that the log output does not provide information for (Figure 13).
Figure 11: Overview of the packets captured during the execution of the malware.Figure 12: Indicator that only some of the actions are performed while the rest provided an invalid IOA based on our lab configuration setup.Figure 13: The output of Industroyer2 as seen from the CLI.
Conclusions
Overall, we can see that the attackers can tailor their malware to fit each targeted environment and at the same time be extremely effective. Industroyer2 appears to have its industrial communications capabilities properly implemented. However, a lot of similarities to the first version of Industroyer such as the included debug messages, make Industroyer2 detectable with the YARA rules of the 2016 variant.
Acknowledgements
Advice and input given by Cameron Williams and Scott Shoup have been a great help in the technical analysis of this sample.
In this report we provide a glance to a malware coined as Agent Tesla and its sandbox evasion and data exfiltration methods. Agent Tesla is an easy-to-use infostealer malware written in .NET, that includes keylogging capabilities, exfiltration of credentials and other information. One of the most recent versions of Agent Tesla, can also steal data from a victim’s clipboard, as well as browsers,email clients, and virtual private network (VPN) client software. Additionally, it targets Microsoft’s Anti-Malware Software Interface (AMSI) in an attempt to de-feat the installed endpoint protection software. This report investigates the latest versions (v2 & v3) of the malware that has been found in the wild in 2021. Disclaimer: This post was created based on a report that was submitted as final project for the CS504-41: Advanced Forensics & Malware Analysis course for Spring 2021 at University of Idaho.
Introduction
The malware consists of two stages as depicted in Figure 0.1. In the first stage, the malware is dropped in malicious spam emails as an attachment. This downloader part checks the presence of AMSI in the system and then tries to disable it. Then it attempts to download the second stage from websites such as Pastebin and Pastebin clone called Hastebin. It combines the various chunks downloaded to enable the Stage 2 part.
Figure 0.1: The stages of Agent Tesla v2 & v3
The second stage of the malware, tries to avoid sandbox analysis through debugging. Once the checks are passed successfully, the decrypted part creates a child process, and then injects itself to another process using the process hollowing technique. Then it uses an exfiltration carrier type that can be either HTTP, SMTP, FTP, or TELEGRAM. Then it proceeds with the infostealing parts such as browser credential gathering and copy of clipboard contents.
The main differences between v2 and v3 of Agent Tesla are the improved techniques of evasion of sandbox defenses and malware scanners, and the additional C2 options.
We acquire the malware samples to perform our analysis from various sources [1], [2], [3].
AGENT TESLA STAGE 1
We begin our analysis with the first stage of Agent Tesla. For our analysis we use a Windows 7 64-bit VM, running the tools provided by FireEye’s Flare VM.
BASIC STATIC ANALYSIS
Inside the VM, we use a tool called PEStudio that provides us with all the required utilities to perform some basic static analysis.Some interesting facts are presented in the next Figures.
Figure 1.1: Overview of the Agent Tesla downloader
Figure 1.2: Some obfuscated strings of the Agent Tesla downloader that are not recognized by PEStudio
Figure 1.3: The use of Digicert by the Agent Tesla downloader
We see that the malware’s name is Order 5939.bin and is compiled using .NET (created either with C# or Visual Basic programming languages) in Figure 1.1. By investigating the strings section, we see some level of obfuscation (Figure 1.2). We also notice that the malware makes use of digital certificates in Figure 1.3.
With these details in hand, we can perform some Advanced Static Analysis.
ADVANCED STATIC ANALYSIS
We will use the tool DnSpy, a reverse engineering tool for .NET malware. In a .NET compiled executable, the code is compiled to Microsoft Intermediate Language (MSIL). That means inside the code exists a lot of metadata that allows decompilation to be performed. DnSpy is a great tool for this job
Figure 1.4: Use of LoadLibraryA from the Agent Tesla downloader
Figure 1.4: Use of LoadLibraryA from the Agent Tesla downloader
We can see from Figures 1.4 and 1.5, that the malware imports the LoadLibraryA and GetProcAddress. LoadLibraryA is responsible for loading a module specified as parameter into the address space of the calling process. In conjunction with that, GetProcAddress retrieves the address of an exported function or variable from the specified dynamic-link library (DLL). We can assume that the malware, tries to manipulate another process at this point. We notice that the malware tries to obfuscate its actions using string replacement.
Figure 1.6: Use of Registry from the Agent Tesla downloader
In addition we see that the Tesla downloader queries the registry for some particular value. We once again see an attempt to obfuscate its actions using string replacement techniques.
BASIC DYNAMIC ANALYSIS
In this section we examine the malware by executing it and capturing various events such as the network communication, Registry queries, load of libraries and memory artifacts.
We first inspect the traces that the malware leaves to the host by network communications. Having Wireshark running, we execute the malware. We see that it tries to check the revocation status of its certificate using the DigiCert’s OCSP as seen in Figure 1.7. Furthermore we observe that the malware reaches to hastebin.com, possibly to acquire additional components (Figure 1.8). Notice that the VM that the malware executes communicates only with another VM that provides fake network services such as HTTP and DNS, Therefore the malware cannot reach the Internet, although we can investigate its behavior.
Figure 1.7: Agent Tesla downloader attempts to reach DigiCert’s OCSP
Figure 1.8: Agent Tesla downloader attempts to reach HasteBin.com
We also use the program Process Monitor (ProcMon) to inspect any other interesting behavior. We notice that the malware queries the registry for the current version of the OS as seen in Figure 1.9
Figure 1.9: Agent Tesla downloader searches the Registry for the current version of Windows
ADVANCED DYNAMIC ANALYSIS
To examine the malware’s behavior in a greater extend, we use the build-in debugger that comes with DnSpy. This enables the detailed inspection of the values that each function call returns.We can also change these values “on-the-fly”, to make the malware unleash all it’s capabilities.
We set a few breakpoints to places that we found particularly interesting in Section Advanced Static Analysis. In Figure 1.10 the malware searches for the AMSI service. The VM that is used for this analysis is based on Windows 7, therefore the AMSI service is not present (only exists in Windows 10). For that reason, the malware fails to find any amsi.dll files as demonstrated in Figure 1.5. Based on this fact we can safely assume that the analyzed version of the malware, mainly targets Windows 10 systems.
Figure 1.10: Agent Tesla downloader tries to load AMSI
Figure 1.11: Agent Tesla downloader fails to find AMSI
Figure 1.12: Agent Tesla downloader tries to get the address of AMSI
The Agent Tesla downloader also tries to reach the hastebin.com website to download some additional components as seen in Figures 1.13 and 1.14. This comes into agreement with the behavior we analysed in Section Basic Dynamic Analysis.
Figure 1.13: Agent Tesla downloader performs request to HasteBin (1)
Figure 1.14: Agent Tesla downloader performs request to HasteBin (2)
Last but not least we verify the check of the current version of Windows (Figures 1.15 and 1.16). As we see, the return value on our Windows 7 system from this check is false and the malware exits. We have the ability to patch the return value, however this step is out of the scope of the present analysis.
Based on this fact (and in conjunction with the AMSI check), the malware seems to search for a Windows 10 system. Nevertheless, further investigation is needed to validate this assumption, that does not take place in this report.
Figure 1.15: Agent Tesla downloader checks the current version of Windows (1)
Figure 1.16: Agent Tesla downloader checks the current version of Windows (2)
AGENT TESLA STAGE 2
We perform the same steps to analyze the second stage of Agent Tesla. Notice, that the examined sample is not downloaded automatically during execution via the network from the malicious sources. Rather it is acquired manually
BASIC STATIC ANALYSIS
In Figure 2.1 we see information that the malware launches in or makes use of a graphical environment. This is also verified by the fact that we see the use of Expand, Replace in Figure 2.2, and get_PictureBox1 in Figure 2.3
Figure 2.1: Overview of the Agent Tesla loader
Figure 2.2: Overview of the Agent Tesla loader’s functionality
Figure 2.2: Overview of the Agent Tesla loader’s functionality
Not enough information can be gathered at this point, therefore we proceed with some analysis of the code in Section 2.2 and some dynamic analysis in Section Basic Static Analysis.
Nevertheless, after we extract the injected sample from the memory, we use PEStudio once again. We analyze both PE executables and notice that the first one is the legitimate RegSvc (Figure 2.4, and the second the malware (Figure 2.5). The latter makes use of Mail libraries, a Telegram URL and a random name for the copied executable in Figure 2.6.
Figure 2.4: Overview of the benign RegSvc file
Figure 2.4: Overview of the benign RegSvc file
Figure 2.6: Overview of the injected Agent Tesla infostealer part (2)
ADVANCED STATIC ANALYSIS
By examining the section with the resources of the malware, we notice an image (shown in Figure 2.7) that looks like static. We assume that the malware makes use of steganography techniques to hide another payload inside that image, that will be extracted during runtime. We verify this assumption in Section 2.3
Figure 2.7: Image resource of the Agent Tesla loader
As mentioned in 2.3, we have extracted the contents from the memory location where the injected RegSvc exists. We load this sample once again to DnSpy and we examine the following characteristics.
We see the use of the Telegram URL that we noted earlier, in Figure 2.8. Keyboard functionality is present in the function seen in Figure 2.9, and use of the host’s Clipboard in Figure 2.10. A Tor client URL is also present in Figure 2.11, however is not used anywhere in the sample that we investigate (other samples may make use of it). The malware has also the capability of taking screenshots of the infected host as seen in Figure 2.12. Last but not least, Agent Tesla makes use of Anti-Debugging techniques that aims to render its analysis harder (Figure 2.13).
Figure 2.8: The Telegram URL of the Agent Tesla loader
Figure 2.9: Use of keylogging capabilities from the Agent Tesla infostealer
Figure 2.10: Use of clipboard from the Agent Tesla infostealer
Figure 2.11: Tor Client URL of the Agent Tesla infostealer
Figure 2.12: Use of screenshots functionality from the Agent Tesla infostealer
Figure 2.13: Use of Anti-Debugging from the Agent Tesla infostealer
BASIC DYNAMIC ANALYSIS
We execute the sample by having Process Explorer (ProcExp) and ProcMon running. Once the malware is loaded in memory we see that it creates a simple process as seen in Figure 2.14. However, after a while, we see that another process is created, namely RegSvc (Figure 2.15). This is a process hollowing technique [4], where Agent Tesla suspends the state of a legitimate process, then unmaps (hollows) the used memory location and loads the malicious code. This is also verified by ProcMon where the legitimate RegSvc seems to be loaded in memory (Figure 2.16)
Figure 2.14: Agent Tesla loader, basic process
Figure 2.15: Agent Tesla injected process
Figure 2.17: The use of ProcessDump to extract the malware from memory
To further examine the injected malware, we use the ProcessDump (pd64.exe) program to extract all the artifacts that exist in the memory location of this process (Figure 2.17).
Furthermore, we observe some interesting events logged in ProcMon. The malware copies itself into …AppData\Roaming… (Figure 2.18) and creates a Scheduled Task on the host (Figure 2.19). The scheduled task is meant to execute upon logon of the user as demonstrated in Figure 2.20
Figure 2.17: The use of ProcessDump to extract the malware from memory
Figure 2.18: ProcMon shows the copy of Agent Tesla to …AppData\Roaming…
Figure 2.19: ProcMon shows the use of a Task Scheduler
Figure 2.20: Agent Tesla Scheduled Task
ADVANCED DYNAMIC ANALYSIS
Since most of the functionality for the Stage 2 has already been revealed in the previous Sections, we perform a short examination of the exfiltration methods using the DnSpy debugger. In Figure 2.21 we see that the malware has acquired some credentials from the host and tries to send them via SMTP. The credentials can be harvested amongst others, from browsers, email clients and the OS.
Figure 2.21: Agent Tesla attempts to send the harvested information via SMTP
CONCLUSIONS
We examined Agent Tesla from its two-stage perspective. Since 2014, the malware has kept evolving. We see that the malware gets updated and modified by its authors to include functionality that aims to evade endpoint protection tools. We further notice that, with the wide adoption of services like VPN from various organizations, the malicious actors find another source of valuable information that can target. Therefore, it is essential that organizations should educate their users and keep their staff informed of the latest tools and techniques the adversaries are using, particularly in work-from-home cultures and environments. In this report, we provide a resourceful examination of the mechanisms that make the malware one of the most common threat to credential theft. Nevertheless, Agent Tesla is a very complex malware and we have analyzed only a part of it. The interested reader can refer to more extensive reports [5] [6].
Hello all, a few months ago I was going to present into a local event during the Global Azure Bootcamp 2019 in Athens, Greece. The main topic of the presentation was how you can use Azure IoT Hub in the industrial sector. I thought it would be a nice approach to use Python considering that is an easy programming language that almost everyone that has some programming experience can follow without any difficulties, thus that Microsoft has an Python SDK for IoT hub. The issue that I encountered was that my Ubuntu 18.04 operating system was using Python 2.7.15 and Python 3.6.8, so when I was trying to download the appropriate packages through pip some compatibility errors where raised, not letting me move forward. After many hours of trial and error and searching, I gave up and used the NodeJs SDK since I had already installed the same version of NodeJs in my system.
This problem make me think that there must be a way to install programs, packages and frameworks into an alternate environment, by not making changes in the host system or spending hours fixing potential issues regarding the dependencies of each project. Of course there are Virtual Machine (VMs) but for most system the resource consumption reduces the productivity of developers especially on large projects. After some research and remembering my previous occupation with Docker, I tried to investigate that option.
In this blog post we are going to create a portable, reusable and simple in development environment based on Docker by using Python as our programming language and Visual Studio Code as our editor.
(NOTICE: This is not going to be a step-to-step introduction to docker neither to any of its components like volumes, networks etc. For more info about these topics, see the links at the end of this post)
The example scenario that we will investigate consists of a Python file that reads the databases’ names that exists in the MySQL RDBMS.
First of all, we need docker and docker-compose installed in our host system. Information about how to install both of them in different Operating Systems can be found in this link: https://docs.docker.com/compose/install/. We will also need Visual Studio Code (VS Code) as our editor/IDE, that can be found here: https://code.visualstudio.com/download
Once the installation of both docker and VS Code has finished, we open VS Code and create a folder that will include out project. Additionally, some extensions must be installed in order to make the debugging process more efficient and less painless. By going to the left menu, on the Extensions option we search for Docker and Remote – Containers and we install both of them.
Installing Docker VS Code Extension
Installing Remote Containers VS Code Extension
After that, we create a file named docker-compose.yml. This file will contain all our services that we can later deploy with a single command. In our example scenario the first thing we should specify is the MySQL database. By going to DockerHub (https://hub.docker.com/_/mysql ) we can find the snipped on how to create the MySQL container from the ready image that exists there. We copy this example and paste it in our docker-compose.yml file as shown below:
docker-compose.yml with MySQL
Create a .env file also in order to include our secrets for the MySQL container configuration. Docker compose will automatically search for a .env file when it sees the variable symbol (${…}) inside the docker-compose file.
Furthermore, we need a python container to run our actual code. By relaying again to ready images from the docker hub, this time we will create a Dockerfile instead of putting configuration directly to the docker-compose.yml. We create and folder named app inside our main project’s folder and we include the Dockerfile. We also add the main.py file that will run our code, a requirements.txt file for the Python packages and a copy of the .env file so we could be able to connect to the database once the container runs.
Dockerfile
For our simple proof-of-concept code we just include a connection with the MySQL and a command that returns the name of each individual database that exists. The packages in the top of the main.py can be found inside the requirements txt.
main.py
requirements.txt
Now we are ready to include the configuration for the python container in our docker-compose.yml. We simply add the context of our demo-app, a name, we expose the same port that was included in the Dockerfile and we assign the same network as we did with the database so these two could communicate.
And here we are, our environment is setup! We can open a CLI now and test that everything runs as we want. By running the command docker-compose down && docker-compose build && docker-compose up -d we delete any previous containers, we build the containers from the images include in the docker-compose file and we run them in the background. We can verify that our containers are up and running by typing docker ps in the CLI.
The final docker-compose.yml file
docker ps command output
Now we want to be able to debug our app and check for potential issues in our codes or just to inspect the flow of our code. To do that we go to the docker extension we installed in the beginning and find out python container named my_app. Then right click the container and select Attach Visual Studio Code as shown in the image below.
Locate python container in Docker Extension
This will open a new VS Code window where the extension will instantiate a connection with the selected container. If we click on the notification to the right bottom of the window, we should see something similar to following:
We can then set a breakpoint any where inside our main.py file and go to Debug –> Start Debugging or the press the F5 button and voilà! We can now debug our app inside the container!
Debugging the python container
So that’s it. With some simple steps we have created an isolated and reusable across the whole team development environment. You can find the code and all the configuration files for the tutorial and here
Please share your questions, comments, concerns and also check my other posts! Let me what you think or what you would like to see next! 😀
Hey there, today we are going to see how we can implement a HTTP Public Key Pinning (HPKP) in just a few simple steps, to ensure the protection of the data that are transmitted from an app to another.
Hello there, today we are going to get involved with a feature for mobile apps that i recently needed to one of my apps, called Dependency Injection.
(Image taken from https://xamarinhelp.com/xamarin-forms-dependency-injection/)
We are going to give some info and guidance on how to perform platform-specific tasks in the Xamarin.Forms framework and especially how to save and open a PDF file with the default viewer on each platform.
Hey, it’s been a long time since the last post, but I’m back with a nice subject.
At this post we will see about Mobile Apps in Azure App Service and how we can benefit from them.
Mobile Apps in Azure App Service offers a highly scalable, globally available mobile application development platform with a rich set of capabilities to mobile developers.
A few months ago, i was assigned to make a free-topic project for Networks and Cloud Technologies class at my University’s Department of Information
& Communication Systems Engineering. Me and my team (Manolis Andreopoulos and Nikos Valakitsis) decided to get involved with Docker.
Onstage at Google’s I/O developer conference, Sundar Pichai the CEO of Google announced that the Android operating system now has more than 2 billion monthly active devices. Also according to StatsCounter, in March, Android overtook Windows as the world’s most popular operating system in terms of total internet usage across desktop, laptop, tablet, and mobile combined.
By why Android is so big? Well, there are several reasons for that.
Recently i noticed that Windows Notepad used ANSI as default encoding in all it’s .txt files, when i tried to move a mail that i wrote to my Ubuntu 16.04 system to send it from there. Default text editor gedit opened the file that looked like this:
This happens because gedit does not support ANSI Windows-1253 (Greek) by default. So there are many ways to make this work such as adding support for ANSI. But a quicker and more elegant way is to use iconv (https://linux.die.net/man/1/iconv) the linux build-in program to convert the encoding of characters from a input-file to another file with the desired encoding.
An example of this command is: iconv -f Windows-1253 -t UTF-8 Mail.txt -o Mail2.txt
Then Mail2.txt wil be encoded in UTF-8.
