Search Results for: yara

YaraRET (I): Carving with Radare2 & Yara

2 de September de 2019 Por

During the management of forensic cases, there are times when we find ourselves in a dead end, where after the detection of a critical compromise indicator, we have to approach an analysis with weak evidence.

That is why I decided to develop a carving tool based on Yara rule detection. This tool also had to handle raw files in and be able to carry out a wide variety of options on this data in a flexible way, so I decided to use Radare2.

From this combination was born YaraRET, a file carving tool developed in Go, whose stable version is available in the repository of YaraRules: https://github.com/Yara-Rules/YaraRET

The development version can be found in the following repository: https://github.com/wolfvan/YaraRET

So, during the next article the resolution of a fictitious forensic case with YaraRET will be presented, which is based on the combination of several cases that I have been finding for a few months. [Read more…]

Yara for Incident Handling: a practical case

6 de May de 2015 Por

Yara is an initiative that’s become more and more popular for incident handling, especially over the last year. This project has been widely spoken about on this and other blogs.

Here I’m going to show you a practical example for using incident handling triggered by ransomware. Over the last months there has been an increase in this type of malware that, in spite of the many warnings from those of us working in security and incident handling, is still having quite a big impact. Fortunately, the most recent incidents of ransomware where I have been involved, the compromise has only affected one user each time, which allowed us to focus more on the scope of the encrypted archives than on identifying the equipment that may have been compromised.

Extension identification

One of the first cases we were involved in was an incident with CTB-Locker. On this occasion, a user reported a message appearing on his desktop informing him that his archives had been encrypted and asking for a ransom to recover them. Once part of the incident had been contained by disconnecting the equipment from the network and identifying it as the only one affected (let’s not go into this here) we went on to determine which archives had been encrypted and which ones could be recovered (we would never recommend paying the ransom).

[Read more…]

YARA 101

11 de October de 2013 Por

What is YARA?

When speaking about malware detection, there are mainly three ways of determining if a file is malicious: signatures, heuristics and string signatures.

The most widespread in the antivirus detection systems is the signature based detection, i.e. based in the HASH of a file, check it against a signature database and see if this file has previously been detected as malware. This kind of signature is useless for the detection of unknown malware, and to evade this system you just need to recompile the code in a different system or change a single bit.

In order to try to stop these evasion methods, the heuristic method is usually the chosen one. This method relies on the behaviour of the executable file and, according to the actions that it performs inside the system, it decides if it’s dealing with a malicious file. The main issue of this method is that, as many legit programs perform suspicious actions, it can generate a big amount of false positives.

Last but not least, there is the method which this article refers to: string signatures. This method is based in another kind of signatures, different from the aforementioned kind. Instead of using HASH signatures, it uses text or binary strings that uniquely identify a malware sample. That way, even if the file has been tampered with, if it still contains those string signatures, the analysts will be able to detect and classify the malware sample.

[Read more…]

Purple Team: Why all the fuss? (III). Vectr.io

29 de March de 2022 Por

As you can already guess from previous spoilers, in this third part of the series (see part one and part two), after having made clear the role that Threat Intelligence plays in the Purple Team methodology, we will go a bit more into details about the phases of preparation, execution and lessons learned in an exercise.

Disclaimer: As I mentioned in the first episode, I do not intend to set in stone anything in this article, but rather to give my point of view and provide an overview of a subject for which there is not much documentation, and what I found, is scattered in multiple sources.

After having developed an implementation plan based on the mapping of threats on the MITRE ATT&CK MATRIX, it is time to put all the use cases into practice. To do so, we will use Vectr.io, an open source web platform developed by Security Risk Advisors.

This tool is responsible for centralizing all the coordination tasks of the Red and Blue teams. But far from being a tool just for coordinating exercises, it is also prepared to be used as a sort of logbook of all operations executed in various exercises and their outcome over time, so that the evolution of the organization’s security posture can be tracked.

With an abstract description such as the above, it may be difficult to imagine how all of this is accomplished. Therefore, the aim of this post is to opt for a more practical approach.

For the sake of brevity, we will not detail all the functionalities of this tool but will show the possibilities it offers and how these can help us with our goal. It will then be up to you to explore the more advanced functions and evaluate whether they are useful for your particular use case.

[Read more…]

Exchange forensics: The mysterious case of ghost mail (IV)

6 de March de 2019 Por

Articles in the series “Exchange forensics: The mysterious case of ghost mail”: [1] [2] [3] [4]

[Note: This is a fiction story, the characters and situations are not real, the only real thing is the technical part, which is based on a mixture of work done, experiences of other colleagues and research carried out. with the same technical dose but with less narrative, you can consult the video of the talk that the author gave at the 11th STIC Conference of the CCN-CERT here]

We return to the investigation of the incident by examining what our colleague had found in the OWA logs. If we gather all the information regarding the accesses made from the two IP addresses with the Firefox User-Agent, we find several patterns of interest:
[Read more…]

Case study: “Imminent RATs” (II)

6 de February de 2019 Por
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)]

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

Analysis of Linux.Omni

8 de November de 2018 Por

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

Exchange forensics: The mysterious case of ghost mail (I)

7 de May de 2018 Por

Articles in the series “Exchange forensics: The mysterious case of ghost mail”: [1] [2] [3] [4]

(Note: This is a fiction story, the characters and situations are not real, the only real thing is the technical part, which is based on a mixture of work done, experiences of other colleagues and research carried out. If you want a version with the same technical dose but with less narrative, you can consult the video of the talk that the author gave at the 11th STIC Conference of the CCN-CERT here).

Another day in the office, with a list of pending tasks to plan longer than the beard of Richard Stallman and none of them entertaining: reports, documentation of a couple of projects and the preparation of a meeting is what the menu of the day offers for almost the entire week.
Luckily, the saying that “no plan survives contact with the enemy” in this case works in our favor. The phone rings, and my boss goes straight to the point: “A YARA rule has been triggered from the ATD group in CARMEN of [Redacted] (entity whose identity we are going to leave anonymously, calling it “the Organization” from now on). Take your stuff and rush over there.”

The adrenaline rush at the thrill of the hunt is instantaneous: ATD is our internal name of a group of attackers that we hunted a few months ago on another client, and our reversers ripped the malware open from top to bottom without mercy. The analysis allowed us to detect a series of particular “irregularities” in their way of acting, which allowed us to generate a series of high fidelity YARA rules (that is, false positives practically null). If it was triggered on CARMEN (our advanced intrusion detection tool), then 99% sure to be infected”.
[Read more…]

Analysis of Linux.Okiru

13 de March de 2018 Por

In keeping with our campaign of detection and documentation of IoT botnets, a few days ago we found another threat not classified before. It was first uploaded to the VirusTotal platform on November 3 and is only detected as malicious by 4 antiviruses.

During the article, two variants of the malware will be analyzed, which differ fundamentally in their propagation. The first one was detected in our honeypot systems (specifically for the SPARC architecture). The second one is a variant of the first, which was found under the Intel x86_64 architecture, and which the Netlab360 malware lab echoed a few days ago.

As no records of its identification were found, we decided to classify it as Linux.Okiru, due to the name of its binaries.
[Read more…]

Linux.IotReaper Analysis

14 de February de 2018 Por

A couple of days ago we learned about the existence of a new threat IoT considerably more elaborated than any of the ones detected to date (http://blog.netlab.360.com/iot_reaper-a-rappid-spreading-new-iot-botnet-en/), said botnet has been named by Netlab 360 as IotReaper. So, from the malware laboratory of S2 Grupo we have obtained and analyzed some of the related samples.

Infrastructure

The infrastructure of the network is quite similar to that of the Mirai botnet, which is formed by four elements:

  • Report Server: Responsible for collecting the information sent by the bots.
  • Server Downloader: Responsible for providing malware samples via HTTP. The presence of an element allows the continuous incorporation of updates without the need to leave obsolete versions of the malware.
  • Server C2: Responsible for sending denial of service orders.
  • Bot: IoT device infected by the IotReaper botnet.

[Read more…]