Área de Innovación y Laboratorio de Telefónica Tech

There are many reports on security trends and summaries, but at Telefónica Tech we want to make a difference. The Innovation and Lab team has just launched our own Cyber Security report that summarises the highlights of the second half of 2022. Its philosophy is to offer a global, concrete, and useful overview of the most relevant data and facts about Cyber Security, and it is designed to be consumed by both professionals and amateurs in a simple and visually attractive way. The aim of this report is to summarise the Cyber Security information of the past months in order to help the reader, understand the risks of the current landscape. The information gathered is largely based on the compilation and synthesis of internal data, cross-checked with public information from sources we consider to be of high quality. The following are some of the points that are important to us. News highlights The second half of 2022 has been characterised by several attacks on large companies that have caused a lot of talk. Uber, for example, which used a very human way of circumventing the second authentication factor: the "fatigue" of the administrator by receiving dozens of messages asking for confirmation of access, in a short period of time and also at inappropriate times. Another high-profile attack on LastPass has once again called into question the security of using cloud-based password managers. Many other companies and even countries have suffered attacks, although we have only seen them reflected in their consequences: the leaks. In the last half of 2022. Cisco, Microsoft, Toyota, Revolut And even the personal data of the Chinese population has been leaked. CYBER SECURITY Artificial Intelligence, ChatGPT, and Cyber Security February 15, 2023 Mobile Security Regarding Android, it releases a set of patches every month, usually within the first week. In total, 256 patches have been released to fix various vulnerabilities spread across the six bulletins. Of those 256 patches, 14 fix vulnerabilities that have been rated as critical and could facilitate remote execution of arbitrary code. This brings to almost 500 the number of vulnerabilities patched in 2022. Similar to last year but less serious overall. Concerning iOS, the second half of 2022 closed with 167 unique vulnerabilities patched, around thirty of which are considered high-risk, with the possibility of executing arbitrary code. Some of them affecting the operating system kernel itself. This brings to a close 2022 with 261 bugs patched. The annual number of bugs has continued to grow since the peak of 2017. Governments sometimes need to rely on large organisations to help them carry out their work. When a threat involves knowing the identity or having access to the data of a potential attacker or a victim in danger, the digital information stored by these companies can be vital to the investigation and avert a catastrophe. Apple publishes a comprehensive report every six months on what data is requested by governments, which data is requested and to what extent the requests are fulfilled. We update here some data that we have extracted from the information published by Apple for the first half of the year 2021 (the latest published by Apple) on the activities and requests from governments to the company. This semester, the German government is the one that has generated the most requests for information about devices. Threats study by indicator We have conducted, in collaboration with Maltiverse, a ranking study of the indicators of compromise detected on their platform. In other words, to indicate interesting attributes of maliciousness detected in IP addresses, domain names and URLs over the last six months. We have studied 650,000 urls categorised as malicious. About 20% of the IPs have been seen performing some kind of brute force against authentication systems. This means, for example, making thousands of requests with username and password combinations against an SSH server. 🔵 Download the full report here (PDF) Photo: True Agency / Unsplash

There are many reports on security trends and security summaries, but Telefónica Tech wants to make a difference. The Innovation and Lab team has just launched our own report on cybersecurity that summarises the highlights of the second half of 2021. The philosophy behind, is to offer a global, accurate and useful overview of the most relevant facts and data on cybersecurity and is designed to be easily used by both professionals and amateurs in a simple and visually appealing way. The aim of this report is to summarise the cyber security information of the last few months, adopting a perspective that covers most aspects of the discipline, in order to help the reader, understand the risks of the current landscape. The information gathered is largely based on the compilation and synthesis of internal data, cross-checked with public information from sources we consider to be of high quality. Here are a few points that we believe to be particularly important. News highlights One of the most remarkable news not only for the second half of the year, but for the whole year, came in December. The bug in the Java log processing software, log4j, suffered a critical vulnerability that was not patched. From this point on, there was a relentless search for projects containing this library, new forms of exploitation, patches that were not complete, new vulnerabilities found... It was an obstacle course as attackers incorporated these vulnerabilities into their set of attack tools. This failure opened up an interesting debate: up to what point can such widely used, ubiquitous and relevant software be maintained on the free time of a single person? This incident made us think about the role of open-source software in the industry, how vendors use it freely but do not all provide support to its creators in return, which creates a very unbalanced dependency that can later turn against them: the software will inherit potential bugs introduced by the developer. Fuente: https://xkcd.com/2347/ Mobile Security The second half of 2021 ended with 250 CVEs or vulnerabilities fixed for Android, 29 of them critical, very similar divs to previous semesters. However, many of these flaws affect the software or firmware of particular manufacturers, which means that the same vulnerability does not necessarily affect the entire Android device fleet, but only those with the affected components. For Apple iOS, the second half of 2021 closed with 120 patched vulnerabilities, 40 of which are considered high-risk, with the possibility of executing arbitrary code. Some of them affect the core of the system itself. In this report you will find a summary of the main conclusions that can be drawn from the report that Apple publishes on the data requested by governments, which ones and to what extent the requests are met by 2020. We can highlight that Spain is the country that has made the most requests for account information due to fraud in 2020. OT Security Telefónica Tech believes that it is essential to have a holistic vision of security that incorporates industrial environments. For this reason, we have internally developed the Aristeo project: a network of industrial decoys that use real OT devices to confuse attackers and extract the necessary information to generate intelligence that strengthens our clients' defences. More information: https://aristeo.elevenlabs.tech In our OT threat analysis, we have been able to verify the truth of the statement that criminals are the ones who know the legislation and the reality of society best. As an example of this reality, we can see in the following graphic how, as soon as the omicron variant appeared, certain types of attacks in the OT area related to the increase in teleworking increased. Access full report

Emotet returns Security researchers from Cryptolaemus have identifed what seems to be the reappearence of the popular Emotet malware, whose infrastructure had remained inactive since January after a joint intervenion by security forces worldwide to thwart its operations. The new samples used the same propagation mechanism traditionally linked with this botnet: malspam with Excel or Word attachments or ZIP files protected with passwords, spoofed senders and information stolen from old victims' email threads. The only important difference lies in the use of encypted communications with the C2 severs through HTTPS. Even though it has been only one day since the detection of the spam campaign, other researchers have started warning about this new Emotet activity and its delivery as second payload by the Trickbot malware. Operators of this same malware, Trickbot, who are known by the alias of ITG23, have been recently spotted participating in several campaigs along with the Shathak (TA551) threat actor, in attempts to delivery its malware as a previous step of a compromise with the Conti ransomware. More information: https://isc.sans.edu/diary/28044 0-day in FatPipe VPN actively exploited The FBI has issued a statement warning about an advance persistent threat (APT) abusing a 0-day vulnerability in FatPipe VPN devices since at least last May. Specifically, FBI forensic analysis claims that the attackers could have accessed the file upload function in the device's firmware and install a webshell with root access, leading to elevated privileges in the internal networks of the targeted organizations. The 0-day vulnerability described affects FatPipe MPVPN, IPVPN and WARP virtual private network (VPN) devices and is not yet identified with a CVE number or criticality. FatPipe has already released a path and a security advisory (FPSA006). The FBI advisory also contains YARA rules and indicators in order to identify related activity on the systems. More details: https://media.telefonicatech.com/telefonicatech/uploads/2021/1/146982_211117-2.pdf ChainJacking: new software supply chain attack Security company Intezer, together with Checkmarx, has published a paper on a new supply chain attack against sofware providers that could put at risk several common use management tools. Known as "ChainJacking", the attack consist on the modifitacion or corruption of Github, Go Package Manager or NPM open source packages that are included by default in management tools. In the case of Github, an attacker could claim ownership of an abandonned username and start delivering malicous code to anyone downloading the package, taking advantage of the trust gained by the username's former owner. By exploiting this in a repository of Go packages, it could lead to a chain reaction that would amplify the spread of the malicious code and would infect a wide range of products, causing a damage comparable to that of last year's Solarwinds incident or that of this year's Kaseya attack. So far, no active exploitation of this attack has been reported, but this cannot be overlooked given the recent tendency of software supply chain attacks that are difficult to detect, have a huge impact, and give threat agents further changes of infection. All details: https://www.intezer.com/blog/malware-analysis/chainjacking-supply-chain-attack-puts-popular-admin-tools-at-risk/ 0-day vulnerability in ManageEngine ServiceDesk Researchers from IBM have discovered 0-Day flaw in the ManageEngine ServiceDesk engine. This is a widely used help desk management platform that includes applications for the management of projects and IT services. The vulnerability, CVE-2021-37415, could be exploited to grant access to an unauthorized attacker in a API rest subset of an application, which is responsible for the recovery of information from the existing tickets within said application. Moreover, upon successful exploitation, a threat agent could access confidential data through the Internet, including information on the patches to be applied or the internal network structure of an organization, among others. Also, this could lead to a supply chain attack, due to the widespread use of this product and the nature of the vulnerability. ManageEngine has issued version 11302 to correct the flaw and that shall be applied as soon as possible. Discover more: https://securityintelligence.com/posts/zero-day-discovered-enterprise-help-desk/

Kaseya VSA incident On Friday July 2nd, the Revil ransomware group compromised third party companies by exploiting a 0day vulnerability in Kaseya VSA. Kaseya VSA is a remote system monitoring and management solution widely used by Managed Service Providers (MSPs) in the US and UK. The compromise of this solution allowed attackers to gain access to the workstations and corporate networks of hundreds of MSP customers to install their payload and encrypt their files. According to Huntress' traceability of the incident, the attack vector was an authentication bypass flaw in the Kaseya VSA web interface, which allowed unauthorised code execution via SQL injections. The Revil ransomware group has asked for 70 million US dollars to decrypt the affected systems. In terms of the impact of the incident, it was confirmed that it was focused on VSA servers in customer premises (on-premises), so the impact was reduced to around 40 customers, according to the company. Therefore, the rest of the VSA solutions in the cloud and associated SaaS services would not be affected, even though initially when the incident became known, the disconnection of all SaaS servers was requested. Despite a more limited number of potentially affected customers, the risk arises from the fact that some of these customers are managed service providers (MSPs), which could in turn affect their customers. According to the telemetry of ESET, which applied detection rules for the Win32/Filecoder.Sodinokibi.N ransomware variant on July 2, the bulk of the compromises appear to be taking place in the UK, South Africa, Canada, Germany, the US and Colombia. So far, on a preventative level, it remains recommended that customers using Kaseya VSA on-premises disconnect VSA servers and make use of the tool provided by Kaseya to locate IoCs on VSA servers and VSA-managed machines to rule out possible compromise. Learn more: https://www.kaseya.com/potential-attack-on-kaseya-vsa/ Cobalt Strike distribution using the Kaseya VSA incident as a lure Malwarebytes researchers have detected a malspam campaign that is using the fallout from the Kaseya incident as a pretext to distribute Cobalt Strike to potential victims, masquerading as Microsoft security updates. In this campaign, the attackers attach a malicious file with the name "SecurityUpdates.exe" as well as a link that redirects to a URL (hxxp://45.153.241[.]113/download/pload.exe). From this URL, a supposed Microsoft update is downloaded to help protect against ransomware threats. It is worth noting that this same methodology was used by threat actors to also distribute Cobalt Strike after the Colonial Pipeline incident. All the details: https://twitter.com/MBThreatIntel/status/1412518446013812737 Microsoft update does not always fix PrintNightmare Microsoft has released an urgent security update to patch the critical vulnerability known as PrintNightmare (CVE-2021-34527) for which only mitigating actions have been provided so far. This vulnerability allows remote code execution with system privileges through the Windows Print Spooler service, giving an attacker the ability to install programs, view, modify or delete data, and even create new accounts with full user rights. Once the patch was released, several prominent security researchers reported that they have managed to bypass, under certain conditions, the Windows security update released to patch PrintNightmare, again replicating locally and remotely the vulnerability in the printing protocol. The origin of the vulnerability lies in a poor implementation of the updated code, which would allow an attacker to remotely execute arbitrary code when PointAndPrint policies are active and warnings are disabled when installing new drivers (PointAndPrint NoWarningNoElevationOnInstall = 1). Microsoft has not yet made any statements on the subject. Therefore, it is still recommended to disable the print function on any system where it is not strictly necessary, whenever possible. All the details: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527 Analysis of the GrimAgent malware, linked to Ryuk's operations Group-IB researchers have carried out a technical analysis of the GrimAgent malware, a new backdoor related to Ryuk's operations following the dismantling of previously used infection vectors such as Emotet and Trickbot. The link between this malware and Ryuk was established through analysis of GrimAgent's C2 servers, as when a request was made to the malware's C2 domain, it returned content designed for Ryuk's victims. Based on this relationship, the researchers suggest that GrimAgent is being used as part of Ryuk's operations. They also note that no sales on underground forums related to this malware have been identified, nor any use of the malware in the infection processes of other ransomware families. GrimAgent's main functions include the collection of system information (IP, location, OS, usernames, privileges, etc.) and the download and execution of shellcodes and DLLs. Researchers also highlight the ability to circumvent different security measures, which indicates that we are dealing with a meticulous and highly capable actor. More info: https://blog.group-ib.com/grimagent Vulnerability in access to QNAP NAS devices QNAP has fixed an unauthorised access vulnerability in the security of its network-attached storage (NAS) devices. This vulnerability (CVE-2021-28809), discovered by researchers at TXOne IoT/ICS Security Research Lab, is due to a bug in the software code that does not properly restrict access privileges, allowing an attacker to escalate privileges, execute remote commands and compromise the security of the device, gaining unauthorised access to sensitive information. QNAP recommends upgrading to the latest version available for its HBS 3 devices: QTS 4.3.6: HBS 3 v3.0.210507 or later, QTS 4.3.4: HBS 3 v3.0.210506 or later, and QTS 4.3.3: HBS 3 v3.0.210506 or later. QNAP NAS devices running QTS 4.5.x with HBS 3 v16.x are not affected. This is not the first time QNAP has had to fix vulnerabilities of this type recently, having had to fix in April this year a poor access management issue that gave backdoor access to its devices, and which ended up being used by several ransomware operators Qlocker, Agelocker or eChoraix. More: https://www.qnap.com/en-us/security-advisory/QSA-21-19

Over the past few months, many IT departments have been busy carrying out this task of adaptation in order to comply with the new regulations on cookies. Every time we visit a website, we are asked whether we want to accept or (almost always indirectly) refuse cookies. Most users who arrive at this message looking for a service or specific information end up accepting all the cookies without knowing the real impact in terms of security and privacy. How many cookies are usually accepted? For how long? Do the websites respect the new law on cookies? In TEGRA, the Galician centre of innovation in information protection of the ElevenPaths innovation area and laboratory, we wanted to analyse the current use of cookies in Spain and their impact and compliance based on a representative sample of the most visited websites in Spain. To achieve this, we have developed and released a tool called Triki, which automates the navigation to a series of websites defined by configuration and performs different navigation flows. We have drawn interesting conclusions which we include in this report, which we will now summarise. Summary of Regulatory Updates to The 2020 AEPD Cookie Guide In collaboration with Govertis, we will explain what has happened in 2020 concerning cookies and their management. The Spanish Data Protection Agency (AEPD), following the entry into force of the European General Data Protection Regulation and several consultations with the European Data Protection Supervisor (EDPS), updated its guide to the use of cookies in July 2020, giving website owners a deadline to adapt to these policies until 31 October 2020. We could summarise the main updates in that the simple browsing is not valid as an expression of a user's consent to the acceptance of cookies. The use of cookie walls is also prohibited if no alternative to consent is offered. Regarding the new features in the management of acceptance and revocation of consent, the most relevant is the removal of the option to obtain consent through the "continue browsing" option. Previously, the option "If you continue to browse, we consider that you accept its use" was allowed and now the ECDC has established that continuing to browse is not a valid way to give consent. As a general rule, some aspects are modified and clarified regarding the methods for informing users about the acceptance, refusal or revocation of consent, through the configuration that must be provided by the editor or common platforms that may exist for this purpose. Finally, regarding third-party cookies, information will be provided on the tools provided by the browser and the third parties and it should be noted that if the user accepts third-party cookies and subsequently wishes to delete them, he/she must do so from his/her own browser or the system enabled by the third parties for this purpose. Methodology To carry out this research on cookies, the 100 most visited domains in Spain have been selected, obtained through the alexa.com website. A tool called Triki has been developed to extract the information. With it, and a personalized configuration per domain, different types of information have been extracted. For each website, a series of flows have been tracked. In addition, for each flow, two types of extractions have been made: extraction without a blocker and extraction using a third-party cookie blocker. The different flows simulated with each type of navigation are: browse: the tool connects to the website without taking any action and extracts the cookies used. It is the part before the consent of the cookies accept: the tool connects to the website, consents to the use of all cookies and extracts them. This is the acceptance part of cookies reject: the connection to the website is made and the necessary actions are taken to proceed with the rejection of the cookies. This is the part that rejects cookies. How Many Websites Does Each Flow Allow? More than 50% of the websites in our survey allow the rejection or configuration of cookies directly, which is ideal. 24% allow only acceptance and redirect the user to the browser's own configuration for rejection, which increases the effort to perform the rejection. 19 of them (19%) do not allow to reject or accept, but they could be sites without cookies that must be notified. At the same time, 9 (37%) use analytical cookies (Google Analytics) and therefore do not comply with the need for express consent expressed by the regulation of cookies of the AEPD. How Many Cookies Are Used Per Site? 14% use more than 90 cookies. The average use of cookies is 27 cookies per website. We also compare our own cookies with third-party cookies. 44% of websites use the same or a greater number of third-party cookies than their own. In the worst cases, 90% of a website's cookies are third-party cookies. On the other hand, 53% of websites use more than 10 cookies before consent. By using a third-party cookie blocker in the browser, it is shown that 96% of the sites use cookies of third parties as soon as the connection is made. Although it may be legal, it is at least rare that they require third-party cookies to ensure the technical functioning or personalisation of a page. In these cases, it is recommended to use a third-party cookie blocker. During our research we have analysed how many sites use Google Analytics cookies before accepting or refusing consent at the stage we have defined as "browse". The results show that 46% of the sites use Google Analytics cookies before consent. We also wanted to check how many sites still maintain Google Analytics cookies after an explicit rejection by the user. The results show that 25% of websites continue to keep this type of analytical cookie even when rejected. Cookies and Expiration The AEPD, in its guidelines on consent, recommends as best practice the renewal of consent at appropriate intervals. This agency considers that the validity of a user's consent to the use of a particular cookie should not exceed 24 months. Based on these indications, we have analysed our dataset to verify whether the extracted cookies comply with this 24-month maximum lifetime requirement for permanent cookies. Around 15% of cookies do not comply with this regulation by using expiry periods longer than 24 months. When we accept cookies from the site visited, we have found more than 100 cookies with a more than 3 years lifetime. The expiration of 50 of these cookies is greater than 20 years. Finally, we have concluded that 96% of the sites analysed use more permanent cookies than session cookies. On average, 86% of the total cookies used on a website are permanent cookies Secure Cookies We also wanted to analyse which security systems are implemented in the established cookies themselves. Let's look at some of the methods analysed: Cookies Secure: if this flag is enabled in the cookie, it would only be sent to the server in an encrypted HTTP request via the HTTPS protocol (HTTP + TLS/SSL). Cookies httpOnly:enabling this flag in a cookie helps prevent cross-site scripting (XSS) attacks, since HttpOnly cookies are inaccessible from the Javascript document.cookie API. But there are more ways to secure a cookie. The __Secure- prefix makes a cookie accessible only from secure sites with the HTTPS protocol. This makes it impossible for an insecure site using the HTTP protocol to read or update cookies containing that prefix on its name. This security mechanism protects against attacks from tampering with secure cookies. The __Host-prefix does the same things as the __Secure- prefix, but at a higher level it restricts access only to the same domain in which it is condivd. Only 2% of websites use the __Host-prefix. None of the websites use the __Secure- prefix. Can Cookies Be Rejected? Only 8% of the websites analysed allow you to reject directly from the main banner (see image). Of the remaining percentage, 22% do not meet the premise that it is "as easy to reject as to accept", since more actions are needed to be able to disable the use of cookies. The remaining 70% who are compliant use marketing strategies to subtly induce the user to accept cookies. For example, with ambiguous buttons that make people think that cookies have been deactivated. The following graph shows the total number of cookies registered in all domains classified by stage, depending on whether or not third-party cookies have been blocked. Before consent, acceptance and rejection. As can be seen from the results, the simple use of a third-party cookie blocker results in a significant decrease in the number of cookies used. Even if all cookies have been rejected. We can conclude that 69% of the domains that allow cookies to be rejected do not completely eliminate the cookies of third parties when they are rejected with the browser. Conclusions None of the websites that only uses technical cookies and/or personalisation cookies gives any kind of warning to the user that this type of cookie is being used. The data indicates that 44% of the websites use the same or a greater number of third-party cookies than their own. In the worst cases, 90% of a website's cookies are third-party cookies. In this case it is recommended to enable the blocking of the use of third-party cookies in the browser to limit the number of cookies. Even if all cookies are rejected completely, many of these third-party cookies are still used in the same way. The regulations indicate that session cookies should be given priority over permanent cookies. However, the data indicates that 96% of the sites analysed use more permanent cookies than session cookies. In addition, on average, 86% of the total cookies used by a website are permanent cookies. The regulations indicate that the life span of these cookies should not exceed two years, however, 15% of the cookies use expiry periods of more than 24 months. 46% of the websites use pre-consent analytical cookies and 25% use them when still rejecting all cookies, so this is in violation of the AEPD policy. DOWNLOAD REPORT

Let’s say you have a valuable file on your computer, such as a bitcoin wallet file (“wallet.dat”), or some other file with sensitive information, and you decide put a password on it to keep it safe. If you use MS Windows maybe you’ve taken steps to protect yourself from clipboard hijacking malware, and now you’re wondering what to do next in the constant arms race against attackers. We know about some malware that try to target and steal your wallet.dat file so the attacker can crack your password offline and then transfer the funds to an account they control, so from Innovation and Laboratory we wanted to create something for Linux users. We wanted the tool to be accessible, so it could be used to protect sensitive files without doing things like recompiling the kernel or configuring SELinux. We ended up with a new tool, dubbed ChainLock. ChainLock can lock any file on your Linux computer such that it can only be opened by a specific application. For example, it can ensure your wallet.dat file can only be accessed by your bitcoin core application and can’t be opened or copied by malware. How does it work? First, we onboard a file with the ChainLock command line program. This encrypts the target file with a strong password, and then a QR code pops up on screen which we can scan with the companion application for smartphones. Now the key to unlock the protected file is only stored on your phone and can’t be found on your computer. An attacker must compromise both devices to unlock your file without permission. That takes care of protecting the file at rest, but locked files aren’t very helpful when you’re trying to use them. We can ask ChainLock to unlock the file, and a QR code pops up. With the companion app we can select the file we want to unlock, then scan the QR code. The app will send the information necessary to unlock the file to your computer using a Tor hidden service. ChainLock now starts a daemon to watch over the file and only allow access from the authorized binary, and then decrypts the file so it can be used. Now the wallet can only be used with the specified application. Nothing else works! ChainLock also supports upgrading or changing the authorized program, so you can always upgrade your wallet application without fear, or migrate to another device. Where do I get it? You can download ChainLock and the companion application at the ChainLock site. If you want a deeper look at how it works, check out the accompanying walkthrough. The walkthrough will guide you through installing and using ChainLock. You can check this video to see Chainlock in action: With this tool we want to give to the community a new technique to ensure their important files are kept safe. We hope you find it useful.

For some time now, the ElevenPaths Innovation and Laboratory team has been working on different projects and research related to the security aspects of SIEM (Security Information and Event Management). One of the projects we have released is a free open source tool called SIEM Attack Framework aimed at the security analysis of these technologies, and which allows us to detect weaknesses in the configuration of some products such as Splunk, GrayLog and OSSIM. Last year we presented it at BlackHat Arsenal 2019, 8dot8 and EkoLabs, where it won the award for best laboratory in EkoParty2019. The tool is still alive and part of our toolkit available to the community. During this 2020 we have been talking about how the development structure is and how we have been attaching the discovery of new SIEMs within the framework in a chapter of our CodeTalks4Devs. In this talk we help the community to understand how the development was planned, how to contribute or modify modules for specific purposes, and also to anticipate that there would be many surprises soon. What have we added in this update? A few days ago, we launched an update of the tool in our repository by adding three more SIEMs to the attack framework to try to facilitate the work of the Red Team and Pentesting team. In this last update we have incorporated the following manufacturers: QRadar, for which we have implemented a brute force testing module to detect the administrator's password. Since the user is always admin it is only necessary to obtain the password to access the web environment, despite being a very slow attack due to some protections. However, the API does not control the number of attempts, so it is possible to perform a brute force attack to detect the API-Key and then extract the complete configuration of the SIEM and user access to the internal database called ARIEL. McAfee SIEM, in this one we have implemented a dictionary attack to detect the user's password that it is called " NGCP " by default. Due to certain configuration restrictions this attack can be slow, and so this is why we looked for another way to obtain those credentials. Therefore, we implemented a new module taking advantage of the fact that the system enables the SSH service by default and that it is possible to access with the root user, but additionally shares the same password as the NGCP user. Once this data is obtained, it is possible to use three other attacks that allow us to obtain configuration information, services, condivd protections as well as to extract the shadow file from the system. And with all this, the complete users of the system. SIEMonster, where we implemented a dictionary attack module similar to the one mentioned in the previous case. Given that this SIEM has condivd the same user for SSH access and for WEB access, called "deploy", it is possible to obtain administrative access to both the web environment and the console. In addition, two attacks were generated to obtain system configuration data and the shadow file to have all the users of the system. ElasticSIEM, we also implement a brute force module by SSH since the operating system that is recommended for its installation enables the service by default. At the same time, for local implementations it does not generate a default web service access control and requires implementing a series of configurations so that an authentication mechanism can be integrated. Likewise, we generate a module that allows us to take advantage of this possible configuration and access the system through the console, to obtain more data from the configuration, although many times this SIEM only needs to be identified within the network. In addition, in this new version, some changes were carried out: The validation of the data entered by the analyst was modified The possibility of specifying a port in a simple way different to the one detected in the installation of the SIEM was added. This way, it is possible to detect it even if it has been published in another port from the tool itself without having to resort to other tools to do so. Test batteries were added to optimize operation. Modifications were made to allow users to see which data can be obtained in some of the attacks and compare with their own results. With all these changes and improvements, the tool´s 2.0 version offers the possibility of analysing seven different SIEMs in different ways. In some of them we can detect and take advantage of weaknesses in their default configuration, in others, in the use of the API management and in others, of the services exposed, but always offering a possibility to evaluate the security of the system.

Few weeks ago, we presented DIARIO, the malware detector that respects the privacy of users, and we continue to improve it so that it detects more and better. We recently added the ability to detect malware in office documents which macros use a technique known as VBA stomping. What is this technique about and why is it so important? We already know that emails with attachments are one of the most popular entry routes for malware, specifically office type attachments. This is largely possible due to the ability to program code into office document macros. There are several reasons why this technique is still in use two decades after it was first introduced: Macros are easy to hide. Macros are legitimate. Even if they are disabled by default, it is easy for the user to enable them. The sandboxing is more complex to emulate them. They are sent by email, so usually they are only analysed statically. The user does not think that a document or spreadsheet can be dangerous. It is still a very lucrative route for cyberattackers. And even though so much time has gone by, innovation in this technique is still going on. The technique of stomping is a test. Firstly, let´s see what a "recent" macro consists of. We will find a binary file, with the extension .bin, inside the .zip file that nowadays are the documents. At least in the most recent versions of Office. The first thing to bear in mind is that in this .bin file there are no macros as such, but a whole system ready to be compiled and executed by Office itself. Yes, it can be compared to any project carried out with Visual Studio, where we have the source code, the definitions, the compiled code... The Office system in use, such as Word or Excel, has an engine for compiling and executing this code. In fact, within this .bin file, we can find the following (if we analyse it with the appropriate tools): PROJECT: flow (file): it is like the configuration file. VBA_PROJECT: flow with instructions for the VBA engine. Not documented. Dir: compressed and has the layout of the project. Module streams of the type VBA/ThisDocument/NewMacros/.../__SPR_1/Module1, which contains the code to be executed. Each module of the code is in turn composed of PerformanceCache and the CompressedSourceCode, which is the source code of the compressed macro. What is all this for? This pursues the obsessive backward compatibility of Microsoft. Let's imagine that we create a document with macros in a recent version of Office, for example Word 2016. We create the macro and it is compiled into the system, but the source code is also stored with it. The person who receives the document may have an Office 2016, in which case, in order to go faster, the compiled macro will be executed directly. But what if you want to open the document with a Word 2003? Then, for compatibility, you must take the VBA source code of the macro, compile it in your engine and run it. And this is the reason why we find "clearly" the source code of the macros in the documents. Historically, this has been an advantage for those who analyse this type of malware: they can access the code effortlessly and analyse it more easily, etc. Antiviruses have relied on this source code even to classify samples. However, someone thought that the document could still be infected if the compiled code was kept but the source code was deleted. And it was indeed. This technique of deleting the source code is VBA stomping, and allows malware to go unnoticed with little impact on its ability to infect. Only those users with unsupported or very old VBA engine versions (Office versions after all) would be spared from the infection. The Evil Clippy tool already exists, capable of facilitating VBA stomping and automating all the necessary processes As it can be seen, DIARIO already detects this type of documents and displays the code even if this technique has been used:

The first time an IoC lay on your hands. Let's say it is a hash, URL, IP or a suspicious domain. You need to know some basic information. Is it malware? Is it in a repository? Since when? Whois? Country of origin? Is it in pastebin? Now, with the new version, it is even easier. You start opening tabs, entering passwords in the different services and the consulting begins. Hopefully you have an API shared with a colleague and after checking several systems, you open a TXT to pass the information to the intelligence platform. Your colleague, with whom you share these APIs and passwords but who is elsewhere in the world, does the same because he has also received the same IoC. This is over with TheTHE. What's New? We have worked to substantially improve the tool. Some of these interesting improvements are the following: We have added a global search for IoCs: it is now possible to search for any IoC that is in TheTHE from a search engine which functionality will be extended with new features. We have improved the project selection interface: it now includes additional information and it is possible to sort out the list in many different ways. We have created a new labelling manager that includes the creation of tags with icons. In addition, it is now possible to delete a created tag and propagate the changes through the system. Now the installer (install.sh) will ask you for the system variables you want to set if it does not detect the presence of an .env file with the variables needed to start the environment. We have created an IoC scanner that detects and extracts IoCs from the results of the plugins. In addition, it is now possible to delete IoCs we are not interested in from the list of detected. The following plugins are added with their respective views in the interface: URLScan and MalwareBazaar. The Threat Hunting Experience We introduced this tool at Black Hat 2019 in London, where it was very well received by its target audience: researchers, SOCs, Threat Hunting teams, security companies, CERTs, etc. TheTHE is a free and open environment designed to help analysts and hunters during the early stages of their work to make it easier, faster and more unified. One of the biggest problems when conducting hunting or IoC research (Indicators of Commitment) is dealing with the initial collection of such large amount of information from so many sources, both public and private. All this information is usually dispersed and sometimes even volatile. Perhaps at some point there is no information from a certain IoC, but this situation can vary in a matter of hours and become crucial for an investigation. Based on our experience in Threat Hunting, we have created this free and open source framework to make the first stages of the investigation simpler: The IoCs are yours: they do not leave your platform and are not shared. Free and open: docked and totally yours. Client server architecture: The research can be shared with your team. The results are cached so that no API requests are wasted. Feed your Threat Intelligence Platform better: TheTHE makes previous research faster and easier. Easy Plugins: Anything you need is easily embedded in the interface. Ideal for SOCs, CERTS and any team. API keys are stored in a database and can be shared by a team from a single point. Automation of tasks and searches. Fast processing of multi-tool APIs. Unification of information in a single interface: so that screenshots, spreadsheets, text files, etc. are not dispersed. Periodic monitoring of an IoC in case new information or movements related to it appear (available in future versions). TheTHE has an interface where the analyst enters the IoCs that will be sent to the backend. The system will automatically search those resources (through plugins) in several already condivd platforms to obtain uniform information from different sources and access to related reports or existing data.