Security Art Work

As any analyst knows, the very nature of Threat Hunting entails the application of generic approaches for the detection of anomalies. Unlike the reactive positions of rule-based security, proactive analysis delegates a significant percentage of detection to the analyst. This means that, as it happens to a conventional intelligence analyst, errors of interpretation tend to occur, due to the large number of casuistry found on a daily basis, and which the brain tends to classify as legitimate or malicious in hundredths of seconds.

According to Richard Heuer’s definition in “Psychology of Intelligence Analysis“, an analyst has limits in the interpretation of information, determined by his personality, his beliefs and his cognitive biases. After the identification of the anomaly, the analyst must be able to make a prediction. That is to say, it is the interpretation of a detection and its association to a possible threat that represents a security alert.

And not only this, but, as defined by Steven Rieber in his “Intelligence Analysis and Judgmental Calibration“, the analyst must also be capable of weighing the criticality of an anomaly, which also remains within subjective positions in the form of subjective probability.

We live in a society that gravitates around information, so there is no doubt about the importance of communication skills and abilities today. Regardless of the type of project, service or activities, knowing how to transmit information effectively and efficiently to those responsible and interested agents is undoubtedly a critical aspect.

Undoubtedly, communication is an essential process of any organization, capable of propelling and revaluing other strategic or primary processes. In the professional field, an important part of this communication is materialized in the reports, due to their more formal nature and element of transmission of information both vertically and horizontally. For this reason, they must respond to the usual principles of communication: transparency and accessibility according to the information classification model, so that they are available to all interested parties; suitability, so that their contents are relevant to the recipients; credibility, providing true, exact and appropriate information; and clarity, being understandable and avoiding all ambiguity. Beyond these variables, it should never be forgotten that reports are often used as decision support tools.

See first and second part.

Hey, hunters! How’s the hunting season going?

After what we saw in previous posts, in this article we will continue to understand and improve our Threat Hunting lab.

We have already learned how to enter our data about real attacks and now we will learn how to exploit that data. Being able to visualize the data in a comfortable way is, along with selecting good data sources, the most important part of a laboratory. All the time we invest in an intuitive and pleasant visualization will be time saved during the analysis.

Now we are going back to the laboratory, this time we are going to learn how to handle some of the HELK functionalities that we have not seen yet.

An Indicator of Compromise (IOC) is defined as a piece of information that can be used to identify the potential compromise of an environment: from a simple IP address to a set of tactics, techniques and procedures used by an attacker in a campaign. Although when we speak of IOC we always tend to think of indicators such as IP or domains, the concept goes beyond this, and depending on their granularity, we can find three types of indicators:

• Atomic indicators: those that cannot be broken down into smaller parts without losing their usefulness, such as an IP address or domain name.
• Calculated indicators: those derived from data involved in an incident, such as a hash of a file.
• Behavioral indicators: those that, from the treatment of the previous ones, allow the representation of the behavior of an attacker, his tactics, techniques and procedures (TTP).

Continuing this series of posts related to the cloud, it’s time to talk about how to face the world of possibilities that the cloud offers. This article aims to shed some light on such a huge task and to show different aspects to be taken into account. It is an interesting path, with multiple options, which can bring enormous value both to the business and to our quality of life, as long as it is approached from an objective, realistic and critical point of view. We should not be reticent to change, but neither should we apply change for change’s sake.

Leaving philosophical mantras aside, saying that the cloud is the panacea makes as little sense as saying that the cloud does not bring value to the business.

As always, and sorry for the insistence, it will depend on each organization and its needs. What is fundamental, within the analysis of the business case and in calculating the return on investment of the implementation of these new technological paradigms, is that the consequences, needs and capabilities of security are considered. Both in the process of migration to the cloud, as well as in the face of any technological change.

Having said this, and getting to the point, there is no doubt that migrating to the cloud has a significant cost. Whether this cost is greater or lesser will depend on how you compare, but it can be said that it is not a “cheap” decision. If we do the simple exercise of comparing a physical server to a cloud server, the difference is fairly clear. However, putting everything into context, and above all, emphasizing security, there are many other costs to be assessed.

The data

In the last post we set a platform to store the data. Now we need to feed it with some data. One way would be to install Windows virtual machines, Winlogbeat and Sysmon, but we will do that later. Now I want to talk about Mordor.

Mordor

This project, also maintained by Roberto Rodríguez and José Luis Rodríguez, is a repository of pre-recorded events while offensive techniques were executed on laboratory machines.

As expected, this project integrates perfectly with HELK and provides us with very interesting data to start hunting our threats. So, let’s go.

Today’s post is a collaboration sent by the team of CSIRT-CV, the ICT Security Center of the Valencian Community, in relation to the detection of a vulnerability in the CMS Tiki-Wiki during last December.

A few months ago, in December 2019, the CSIRT-CV team discovered a vulnerability in the CMS Tiki-Wiki, a WordPress, Joomla or Drupal style content management system.

This vulnerability was published months later, in April 2020, with the code CVE-2020-8966, as can be seen on our alerts page, giving developers enough time to correct the problem detected in the application. All of this was channeled through INCIBE-CERT, which mediated with the developer company. Once corrected and published, and after the problems derived from the Covid-19, we have taken some time to go through its details.

During an penetration test carried out on an internal website using this CMS, several Reflected Cross-Site Scripting (XSS) vulnerabilities were detected on version 18.3, even though its exploitation was still effective on the last available version, v.20.0 at that time.

The XSS vulnerability allows code to be injected into a data entry field on a website: a search engine, a forum discussion field or a data collection form. The intention is to execute the injected code in the victim’s browser after they access the resource. This vulnerability can be persistent, when the injected code is stored on the site and executed in the browser of each user accessing the page, or reflected, when it is not stored but is embedded within the URL, and is sent to the victim to click on, such as an email, a social network link, etc.

Many times, talking to friends who work in other professions, I tell them how lucky we are, those of us who work in the IT industry. We, unlike 99% of the occupations, can create realistic environments for testing, learning, practicing… and when we are done with those environments we can destroy them and the expense of material will have been zero. How lucky we are!

Those of us who are passionate about computer security are even luckier; since its inception the cybersecurity community has been characterized by its defense of information freedom, free software and collective learning, which has made us the best time in history to learn about cybersecurity.

In this case, I want to make a guide to be able to build a Threat Hunting lab from home and at zero cost (not counting the investment of our computer).

Before we get started, let’s make a brief introduction about Threat Hunting, as it is important to settle the foundations of our laboratory.

Following the introductory cloud post a few days ago, and to avoid losing momentum, we are going to keep talking about the cloud, in an area where it seems particularly useful: business continuity. Along with other measures, it is clear that the existence of globally distributed datacenters (did someone say GDPR?), flexible system scaling and almost instantaneous deployment make a cloud infrastructure (on equal terms) more resilient to outages than an on-premise infrastructure. Of course, availability is not the only factor to consider, but we’ll talk about that another day.

However, to speak of the benefits of the cloud, the providers do themselves a pretty good job. What I want to talk about is some of the issues that must be considered before migrating an infrastructure to the cloud (although some of these points are also applicable to PaaS and SaaS). That is: the problems.