Search Results for: cloud

Analysis of Linux.Haikai: inside the source code

8 de November de 2018 Por

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. [Read more…]

The tools of the gods

12 de April de 2018 Por

Today at SAW we are not going to talk about security but about religion. About the true religion, the good one: about Unix. And about its gods: Kernighan, Ritchie, Thompson … we could cite a few. And about the tools that, in the seventies, these gods sent to us poor mortals, like the manna fallen from heaven for the chosen people.

The thing is that these gods created a real operating system, with some technically wonderful tools and a very simple philosophy: simple capabilities that combined make complex tasks. Perfection. Life is Unix running a script. More than forty years have gone by and we, poor mortals who were the chosen people, what have we done all this time? Trying to dishonor that divine legacy with artificial and useless layers (“of abstraction”, they call them, to try to make sense of them) that introduce two unnecessary problems in any “modern” technological environment: complexity, and therefore probability of error, and slowness.

Exemplary is the “true” executable, in line with the story recently commented by Rob Pike on Twitter:


$ >mytrue;chmod +x mytrue
$ ./mytrue
$ echo $?
0
$

A program whose only purpose is to always return 0. An empty executable. EMPTY. There can be nothing simpler that works, and has been for forty years … well, that’s where we mortals come in. Year 2018:

[Read more…]

Publication of the NIS Implementation Regulation (for digital service providers)

12 de March de 2018 Por

(This entry has been prepared in collaboration with Ana Marzo, from Equipo Marzo, which provided a good part of the information).

Just a couple of weeks ago Ana March, from Equipo Marzo, an attorney for whom I have great professional respect, contacted me to tell me about the publication, not expected (at least by me), of a new regulation of the Commission related to the NIS Directive, which I have called in a display of originality NIS implementation regulation.

In fact, on 30 January, the Implementing Regulation (EU) 2018/151 of the Commission from 30 January 2018 was published, laying down rules for the application of the Directive (EU) 2016/1148 of the European Parliament and of the Council with regard to the specification of the elements to be taken into account by digital service providers in order to manage the existing risks for the security of networks and information systems, as well as the parameters for determining whether an incident has a significant impact..

At least it caught me by surprise (and I am sure that some of our readers will see the same thing), since I expected a transposition of the directive, not a regulation emanating directly from the Commission (which does not mean, of course, that we will not enjoy our own NIS-compliant legislation, as the legislator must be kept busy…). Given that, although in different areas, we had both coincided at the same client that fitted into the concept of digital services provider and could therefore be affected, we asked ourselves about the applicability of the regulation to this specific client. For example, is an online newspaper affected? And an online sales website? An online bingo? And the purchase-sale between individuals? Deriving the answer to these questions is the subject of this entry.
[Read more…]

Some vulnerability in ASUS routers

25 de January de 2018 Por

A few months ago, I changed my old TP-LINK router to an ASUS. Since it is the de facto manufacturer recommended by my ISP, in order to avoid any complications that could lead to delays in getting my Internet up and running I decided to go with it.

Then comes a lonely afternoon of boredom, or perhaps out of habit (I wanted to start writing a report:D), so I start by trying a little apostrophe here, a marquee as the Wi-Fi name, , command execution in one of the network diagnostic pages and a long list of etc. In the end, one thing leads to another (you know how that goes…), you get involved and when you’re conscious you have Burp or ZAP open, you’ve gone over halfway through OWASP and you’ve been looking for hours for something to play with, something interesting to see how safe your brand-new router is. [Read more…]

Is your NAS exposed to the Internet?

5 de May de 2017 Por

The widespread use of devices connected to the network, such as cars, medical equipment, industrial controllers (PLCs), appliances, etc., has brought with it a new and extremely vulnerable landscape.

While there has been a breakthrough in connectivity issues (Twitter is everywhere!), the security issue has also been set aside. This is mainly due to the fact that for most users and organizations, Internet security is not a fundamental factor, which is why cases such as Mirai, one of the largest distributed denial of service attacks that has been recorded so far, which is just one of the first cases that we have to face in this new scenario..

The proliferation of interconnected devices has brought many advantages to users (homes, organizations): flexibility, mobility, automation, efficiency, etc., but what happens when we do not take the appropriate security measures and are unprotected by default?

You will then see how a series of small weaknesses can lead to a large leak of information, compromising personal, financial and confidential data, both private and organizational.

[Read more…]

Abusing corporate webmail for C&C and exfiltration

20 de April de 2017 Por

Let’s assume an organization that has basic security measures: workstations cannot make direct connections to the Internet, only being able to carry out web requests through a proxy server, which is also the only one that can make external DNS queries.

HTTP and DNS traffic generated by this proxy server are properly monitored, and the proxy “breaks” HTTPS, so techniques like the domain fronting can also be detected. Only a few whitelisted websites are accessible. [Read more…]

Simple domain fronting PoC with GAE C2 server

31 de January de 2017 Por

In this entry we continue with domain fronting; on this occasion we will explore how to implement a simple PoC of a command and control and exfiltration server on Google App Engine (GAE), and we will see how to do the domain fronting from Windows, with a VBS or PowerShell script, to hide interactions with the C2 server.

The goal

When we have everything ready, we will have a webservice at myc2server.appspot.com which we can use from a compromised Windows machine in the following way; we will have a command and control channel (on the path /e2e7765b71c1, as an authenticator):
[Read more…]

Camouflage at encryption layer: domain fronting

24 de January de 2017 Por

In today’s post we are goint to talk about a somewhat old technique (although programs like Signal have recently started using it) that I have always found to be a really clever hack:
domain fronting.

For example, let’s take the IP address of the frontal that serves www.google.es:

$ host www.google.es
www.google.es has address 216.58.210.227

If we take a look at the Common Name (CN) field of the TLS certificate returned by the server: [Read more…]

The end of passwords … or not

2 de December de 2016 Por

It is more than said and proven that passwords are the key that gives access to our information, and hence we give them so much importance. Today we use passwords to access our emails, the bank, social networks, online shopping sites … in short, we use passwords to access any site; and of course, as passwords must be robust, and on top of that we cannot use the same one for everything, so end up going crazy. That’s why some of us use password managers, mne-monics, etc. because otherwise it is impossible.

img1 [Read more…]

CurrentVersion\Run\Barbicas

10 de December de 2014 Por

Editor’s Note: tomorrow morning our colleague Antonio Sanz is going to be giving a talk on the malware described in this post, and the handling of the incident associated with its detection at CCN-CERT‘s 8th STIC Conferences.

Last August, several possibly targeted employees of one of our customers (a strategic company) received a number of messages somewhat “suspicious” that concerned the then relatively recent crash of the Malaysia Airlines plane.


When opening the document, with a .doc extension, a sort of “statement” regarding the accident in question appeared.


However, a basic analysis revealed that the file was actually an RTF (and not a DOC), and it came with a gift: our old friend, the CVE-2012-0158 exploit. As the file hashes had no public presence in the usual services (VirusTotal, Malwr.com, etc. and obviously it was not detected by the corporate AV), and given the nature of the message recipients, we thought it would not hurt to “play” a little more with the artifact, running it on our sandbox.

After about 12 minutes (!) waiting, the sample finally tried to contact something, and, to our surprise, that something was a public WebDAV provider service. So the malware used that protocol over HTTP (and not over HTTPS, according to the results of our latest tests), for anything it was trying to receive, or to transmit…

Indeed, simulating the WebDAV server to which it was trying to connect in our lab, the sample was trying first to download information from a particular path inside the WebDAV, and then it uploaded into another path some pseudorandom named files (but with known file extensions).


After exploiting, the malicious RTF attachment substituted himself with a “clean” document (the statement about the accident) that it had embedded (so if you tried to analyze the dropped documentseparately, there was no way to repair on the existence of the exploit or the rest of the malware), and opened it with Word, perfectly mimicking the usual opening of a DOC file. However, in background, it was dropping and running a .vbs file, which in turn dropped an embedded DLL file (which it had hexencoded in its own source code).

This DLL (dropped directly into %SystemRoot% if the user had the necessary privileges, or into the user’s profile otherwise) was loaded using the Windows command regsvr32, persisting through an invocation of that command on the usual HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry branch. For this attachment, the key was written with the name Barbicas (a word resembling “small beard” in spanish).


Elaborating on the dynamic analysis of the DLL (static analysis did not throw much more at that point), we note the presence of a packer which took a large amount of CPU time, over several minutes, to unpack its guest (another DLL file). The packer deobfuscated the malicious code on further pages of the memory map of the process, running it (addresses 0x7FF40000 and 0x7FF80000 in the screenshot).


Inside the process memory we could see the URL of the WebDAV server as well as the username and password used to access it, along the upload and download paths, and the extensions of the files that are uploaded.


Once unpacked with standard reversing techniques, it was possible to dump the DLLs (rebuilding their Import Tables) in order to statically analyze in more depth the deobfuscated code. The first thing that struck us was the presence of the AES algorithm initialization tables in the data section of the DLL.


Indeed, the malware uses the AES encryption algorithm in CBC mode.


The key used has a length of 256 bits, being hardcoded in the memory of the sample.


Indeed, the size of encrypted files is always a multiple of 16 bytes, the block size of AES, and the encrypted files include the initialization vector of the block cipher mode (as shown by the parameters used in the calls to the encryption and decryption routines observed during the dynamic analysis we conducted), adding another extra 16 bytes to the file sizes.

So far, we had an unknown malware, capable of connecting to an Internet WebDAV server (an original protocol, in comparison to other documented campaigns), and capable of both downloading (command and control channel) and uploading (exfiltration channel) AES-encrypted information (with a 256 bits key length) from/to different paths of the WebDAV.

But the surprises were not over yet; after analyzing the remaining attachments (remember that several users of the organization received malicious messages), we saw that each one was different from the others:

  • The dropped statement about the plane crash (the “clean” document) turned out to be the same for all attachments
  • Both the dropped .vbs and DLL were distinct for each message (both the DLL name, always trying to imitate some legitimate Windows DLL, and the DLL file contents)
  • The registry key used (Barbicas for the first sample analyzed) was distinct for each dropper
  • Unpacking time was also distinct for each attachment, varying from 8 minutes to more than 15 minutes (in any case, the process was keeping one of the CPUs at 100% usage)
  • The WebDAV server was the same for all samples, as well as the username and password used to log into it (which it does not mean that, for other possible victim organizations or campaigns, were not generating artifacts that used another credentials)
  • However, both the AES 256 bits key and the upload (exfiltration) and download (command and control) paths were different for each analyzed sample (in all cases, all that information was present in the memory of the unpacked DLL)
  • The extensions used in the uploaded files (.TAR, .TIF, .TXT, etc. for the first attachment analyzed) were distinct for each sample

Therefore, it’s clear that what we saw was probably a possible campaign using (so far) unknown malware, and selecting the victims in a highly targeted way. The attackers used some kind of artifact generator; once a copy is generated, it uniquely identifies the victim as well as the exfiltrated information, by its use of distinct accounts, directories, file extensions and AES keys for each mutation. Furthermore, it is clear that this was almost certainly the first phase in what could have been a longer persistence in the victim organization.

We don’t know what it would have been possible to find after a few weeks, or months, of effective compromise.

Update: on December 8, 2014, Symantec (re)codenames the malware (or at least one of its mutations) as Infostealer.Rodagose (Number of infections: 0 – 49, Number of Sites: 0 – 2). We still prefer Barbicas :-)

It’s been over 4 months since we saw the malware for the first time and an AV vendor has begun to to detect it (and so far, we are not aware of more public presence), reporting “few” infected sites (therefore, is it a campaign that has affected several organizations?); the above, and the character of the highly targeted victims we saw in the case of our customer, maintains the “enigma” for the moment. We will try to keep you informed as more information emerges.

Update 2: on December 9, 2014, Blue Coat publishes a report, (re-re)codenaming the malware as Inception. All information in the report is consistent with what our team observed in August 2014. It seems clear that it’s an APT campaign.

Update 3: on December 10, 2014, Kaspersky codenames it Cloud Atlas.