It remains to be seen if Kali Purple will do for defensive open source security tools what Kali Linux has done for open source pentesting, but the addition of more than 100 open source tools for SIEM, incident response, intrusion detection and more should raise the profile of those defensive tools.

For now, Kali is primarily known for its roughly 600 open source pentesting tools, allowing pentesters to easily install a full range of offensive security tools.

In this article, we’ll focus primarily on how to use this powerful OS to run a pentest and mistakes to avoid. We’ll give you an overview of what can be achieved with Kali Linux using a short selection of pre-installed tools. While this guide serves as an introduction to common pentesting phases, with practical examples that highlight best practices, it’s not a substitution for a complete professional pentesting methodology.

Also read:

• 24 Top Open Source Penetration Testing Tools
• What Is Penetration Testing? Complete Guide & Steps
• How to Implement a Penetration Testing Program in 10 Steps
• What Is a Pentest Framework? Top 7 Frameworks Explained

What is Kali Linux?

Kali Linux is a popular pentesting distribution maintained by Offensive Security (OffSec), a 15-year-old private security company. Kali contains scanners, sniffers, and many other attacking tools.

The OS can power a full pentest session or more specific attacks. While there are many other pentesting distributions, Kali is the top one recommended by professionals.

Indeed, most of its pre-installed packages are available as standalone packages, but Kali incorporates and maintains high-quality solutions that are meant for professional usage.

The idea behind the operating system is to have a comprehensive toolbox that is relatively easy to update while following the best standards in the industry.

Kali is built for pentesting only. That’s why you won’t want to install it as a primary OS unless your machine is dedicated to pentesting or it’s a virtual machine.

What’s new in Kali Linux in 2023?

There have been three quarterly releases thus far in 2023, with the first one by far the most eventful.

Kali 2023.1, released in March, introduced a new kernel version and eight new packages, including CyberChef, which is a pretty convenient interface to decipher, decrypt, and decode various strings and hashes with granularity and accuracy.

The release also included a temporary patch to make sure that Python and its PIP package manager worked with Debian’s upcoming Stable release, as Kali is a Debian-based distribution. A bug with Nvidia drivers and some specific GPU models might cause all affected Linux devices to become slow or freeze; a fix was expected.

But the biggest change in Kali Linux 2023.1 was the addition of the Purple Edition for defensive security, which we’ll cover further down.

Kali 2023.2, released May 30, added a Hyper-V VM image that should be much easier for users, requiring no configuration. In addition to other changes, the 2023.2 release added 13 new tools, including a few container and SBOM tools, the Evilginx man-in-the-middle attack framework, the GoPhish open-source phishing toolkit, and TheHive open source incident response platform, among other interesting tools.

Kali’s third-quarter release, 2023.3, dropped on Aug. 23, and the main focus was changes to Kali’s internal infrastructure to coincide with the release of Debian 12. Kali Autopilot, an automated attack framework that debuted with Kali Purple, got a redesigned GUI and other new features.

Kali Linux 2023.3 also added 9 new tools, ranging from cloud and container security to automated pentesting tools, and replaced two tools that are no longer actively supported.

Is Kali beginner-friendly?

Kali is available for anyone. It’s free and open-source, so anyone can download it. It’s a good idea to try things on your own and then read the documentation or tutorials.

However, is it a good place for beginners to start? While Kali IS beginner-friendly, professional pentesting is not something you can improvise. It requires knowledge and planning to be effective.

Here are some requirements for becoming a good pentester:

• Mastery of pentesting basics: legal aspects, scopes, essential steps (such as passive recon, network discovery, enumeration, privilege escalation), post-exploitation, and persistence
• Mastery of the network layers (the OSI model, IP, subnets, and more)
• Mastery of Windows and Linux systems
• Proficiency in Python and some programming languages (like Go, C, C++, Ruby); in my opinion, this isn’t optional, but some security specialists might say otherwise

Some people learn faster than others, but there’s a massive range of tools and concepts to know, so it will take time regardless of your learning skills or speed.

Getting Started: How to Install Kali Linux

Kali Linux is remarkably easy to install. The “Get Kali” page lists various installation modes, with pre-configured images and ready-to-use virtual machines.

Virtual machines are perfect for a quick intro. Feel free to test them, even if it’s just to see what the OS looks like.

Most operating systems are supported, and you’ll find Docker containers, and even support for Android and Raspberry Pi. Windows users can install Kali using the Windows Subsystem (WSL2), for example.

The bare metal installation is not recommended for beginners, though.

You can flash ISO images on an external drive to install Kali on the device of your choice by booting from that drive.

You can also run Kali in live mode with the live distributions without installing it on your device.

Mistakes to avoid with Kali Linux

Without proper knowledge, your pentest will likely fail, as there’s no magic recipe you can apply blindly regardless of how good your tools are.

Besides, attacking tools can send multiple probes or headers along with their requests (e.g., during scanning and discovery), which can be detected and blocked by security tools. Note that Kali won’t hide your IP or cover your fingerprints automagically. You may use a VPN or install utilities to capture and forward traffic to other subnets, or configure proxychains.

You may also leverage external platforms like Linode for your setup and operations.

However, if you are a complete newbie, my advice is to not rush on the tools, and to start with free open-source projects to attack, like the Juice Shop or many other vulnerable applications that are meant to help you learn cybersecurity.

Then you might want to learn more advanced techniques or to invest in dedicated online training programs (see the final section of this article).

Pentesting is not just about servers and web apps

A penetration test aims to emulate a real attack on a targeted system. It’s actually a broad term that covers a wide range of tests and procedures, not just for web apps, and organizations can leverage regular pentests to improve their security and fix critical vulnerabilities.

Unlike vulnerability assessments, pentests involve exploitation, which means you, as an attacker, will hack the system, for real, according to the rules defined before the test. The ultimate goal is to write a good report that provides recommendations.

Note that your pentest is not an exhaustive analysis, as you will likely have limited time and only need one working exploit to achieve your mission.

It’s important to bear in mind that pentesting is not limited to hacking vulnerable servers that host apps and databases. There are multiple other attack angles to test, including:

• Network compromises
• Social engineering (e.g., phishing)
• Memory corruptions
• Wi-Fi attacks

Kali is a wonderful toolbox, because it has tools for a wide range of pentests. Web apps are good for learning because many web servers are vulnerable and expose a large surface to attackers, as organizations have to expose their network to the public.

However, if it’s necessary (and in the contract), a pentester can perform physical attacks too.

Don’t neglect the legal aspects

Laws are not the same everywhere, which means the same procedures can be legal in some countries and illegal in others. It’s especially true if you compare the EU to the U.S.

As far as I know, “Ethical hacking” is not a legally protected status. Legitimate security researchers have been sued after demonstrating critical vulnerabilities.

Scope is essential for distinguishing a pentest from a real attack. Of course, you need an explicit consent, which is usually a legal agreement, to run a pentest, but you must also define the scope very precisely before the operation.

Last but not least, installing Kali Linux at work without permission would raise liabilities too. The distribution contains sensitive programs that can expose your organization, not to mention jeopardize your employment.

Using Kali Linux: Finding Tools

There are literally hundreds of Kali Linux tools for various purposes. Beginners can start with very popular packages for classic and recurrent tasks, or they could ask security pros for their favorite tools.

While the list of tools can provide some hints, it can be confusing for beginners. Here’s a range of pentest tasks and the appropriate Kali Linux tools:

• OSINT: Use Maltego to gather information, Dmitry for passive recon
• Social Engineering: Use SET (the Social Engineer Toolkit)
• Knowledge base: Use exploitdb
• pentesting framework: Use the Metasploit Framework
• Port scanning: Use Nmap to scan the targeted network and Ndiff to compare Nmap scans (e.g., to see which ports get closed/opened)
• Wireless pentesting: Use Aircrack-ng to crack Wi-Fi, Bettercap for recon and MitM attacks on Wi-Fi and BLE (Bluetooth Low Energy) devices
• Packet sniffing: Use Scapy to manipulate packets, Ettercap is also excellent to perform MitM attacks, and Wireshark is a must-have
• Brute-Force URLs: Use Gobuster or DirBuster to scan URLs (directories, files, and DNS), and Nikto to detect server vulnerabilities
• Web fuzzing: Use Wfuzz
• Web hacking: Use BeEF to exploit XSS and other vulnerabilities with the browser or the Burp Suite to intercept requests
• SQL injections: Use sqlmap to crack vulnerable databases
• WordPress scanning: Use WPscan
• Brute-Force logins remotely: Use Hydra (Hydra GTK for the graphical interface)
• Brute-Force passwords: Use John The Ripper
• Active Directory: Use Mimikatz, Impacket

The lists won’t tell you how to use each tool or the right combination to achieve your mission. Once installed, however, Kali Linux sorts packages by categories, which adds some helpful context and labels.

The category usually matches the typical phases of a pentest, like “information gathering” or “post-exploitation,” but also recurrent tasks, such as “password attacks.”

Just open the interactive menu:

Using a Pentesting Framework

The Metasploit Framework can support many steps of your work, from scanning and discovery to exploitation, and even post-exploitation.

On Kali, just open the interactive menu or type “msfconsole” in the terminal to start the console.

The console is verbose, so you’ll know quickly whether the exploit has succeeded. In my experience, the interface provides advanced payload capabilities and a standardized way to use very different hacking modules.

Note that you don’t have to use a framework, but you’ll have to combine several other pre-installed resources to achieve similar results. If you don’t like manual setups (e.g., for listeners) and other repetitive procedures, the console is a great option.

Of course, some cases may require other tools.

Also read: Getting Started With the Metasploit Framework: A Pentesting Tutorial

How To Use Kali Linux for Pentesting

Kali Linux contains many options to help pentesters execute each of the 7 pentesting steps. Here we’ll go through those steps and highlight Kali tools that we’ve found to be particularly helpful.

Step 1: Defining Scope and Goals

Clear goals and scope are critical for the success of your pentest. You and the organization will define the scope and the rules to apply during the test, which ensures there’s no misunderstanding and that there are clear goals.

Your customer will likely have to choose between three common approaches for the test:

• Black box: You operate without any prior access or information about the target and usually focus on gaining initial access
• Gray box: An intermediary approach where you could be given some credentials or internal information just to speed your progression and allow for deeper testing
• White box: These tests are usually longer and focus on the later phases, like post-exploitation or persistence, to challenge the system and see how resilient it is against privilege escalations, insider jobs, or lateral movements

Not all organizations will need a white box test that requires significant time and budget, but it’s sometimes necessary.

You must discuss the timeline and other legal conditions during this step too. It’s critical for your customers to explain in detail what’s allowed and what’s not in a document that will be signed by you and them.

Wild attacks may appear more realistic for beginners, but in practice, it’s not uncommon to whitelist specific IPs that will be used by the pentesters. You need to define a methodology.

Step 2: Recon and OSINT

Reconnaissance, or “recon,” can be either passive or active.

For example, OSINT (Open-source Intelligence) is an indirect way to collect information, whereas Nmap involves active scanning, as you send probes to the targeted network.

Kali has powerful OSINT tools, like Maltego (the community edition is free to use). These programs can help you organize and automate your research.

In any case, you will generally need both passive and active recon during your pentest.

Step 3: Scan and Discover

Let’s say we have an IP/URL to scan. We can use classic Nmap commands to discover services and potential hosts to attack, for example:

nmap -oN nmapscan.txt -v -A {IP/URL}

The -v option is for “verbose” and -A means “aggressive scan,” which is slower and sends more probes to the target, but it’s not problematic here, as we are not in a real case. The -oN option is to export output to a text file with essential results.

If we discover that the server hosts a vulnerable database system, we will attack it.

Step 4: Gain Unauthorized Access and Exploit

SQL injections in a vulnerable database can lead to a Remote Code Execution (RCE).

If we manage to inject malicious SQL queries in the targeted database with sqlmap, we may exploit a typical vulnerability that allows writing files to pass arbitrary commands to the server.

Many exploits consist in uploading a reverse shell, which is basically a “connect-back” channel between your machine and the targeted server.

If such a shell can be opened as a privileged user (e.g., administrator), we’ll get the same privileges for our session!

The root account grants the highest privileges, allowing pretty much any operation while remaining undetected, which is perfect for post-exploitation.

Step 5: Post-exploitation

After exploiting a vulnerability and compromising a network, you may want to show what you can do with it to your customers to prove the impact and the risks associated with the breach.

Metasploit has tons of modules for this purpose, but you can open the interactive menu of Kali Linux to get the full list of post-exploitation tools available:

If it’s a Windows/Active directory environment, Kali has several packages for that, like Mimikatz, a small but powerful utility for Kerberoasting and password dumping, or Impacket, a set of scripts to attack.

Depending on the brief and the size of the organization, you may have to get further access, and progress from the system you’ve just compromised to another.

This technique is called pivoting. You may have to demonstrate that you can maintain access and get deeper into the targeted infrastructure.

Step 6: Clean Up Your Mess

The targeted network must be restored to its original state before you started your operation, which means removing all temporary accounts, scripts, and any other modifications you made on the system.

This phase is usually skipped during a CTF (Capture The Flag event) because the goal is to practice attacking techniques, but in real-world conditions, a pentester must cover all tracks.

Step 7: Report and Make Recommendations

During this step, you will write a report containing the vulnerabilities you’ve just exploited, the potential stolen data, and the recommendations to fix the situation, including technical advice.

The report is the heart of a pentest and a critical document that literally determines the value of your work. It has to be meaningful and readable, so the organization can take concrete decisions to secure its network.

It may contain the following items:

• Techniques used to gather intelligence
• Techniques used to gain unauthorized access
• The threat model and the level of risks
• The estimated value of stolen data and credentials

You must prioritize the most relevant measures. Watch this tutorial by Hackersploit to learn more.

Open-source Alternatives to Kali Linux

There are some alternatives to Kali Linux worth considering.

Parrot OS Security Edition

Parrot OS Security should be very convenient for beginners, with lots of default configurations. Be careful when downloading the archive, though, as Parrot provides a “home edition” that is not meant for pentesting.

You’ll need the “security” edition. It’s still possible to install the home edition and the pentesting tools afterwards, but the security edition is more straightforward.

What I like about Parrot is the ease of use and the privacy-focused approach (no telemetry, anon surf, proxy).

The “Hack The Box Edition” is also worth mentioning. It aims to help beginners quickly set up a machine for a CTF (e.g., on the HTB platform), but you can use it to build a lab or a training environment for other objectives.

Black Arch Linux

You may have read that Arch is for “the real ones” (not beginners), as the installation is said to be more technical compared to many other Linux distros.

That’s not exactly true, as the latest versions are way easier to install compared to the oldest ones. You can now download a “slim” version too.

If you already use Arch, you can “upgrade” your installation to Black Arch with a dedicated installer in minutes.

Linux users may appreciate the core philosophy, which is very different from other distros like Ubuntu or Debian, and the ability to get the latest versions of security packages.

Kali Purple Edition

The Kali “Purple” edition was released recently and ships many popular packages for defensive security, including Yara and DefectDojo. There’s also a large range of forensic and reversing tools to discover.

The team added specific menus that follow the principles of the NIST Cybersecurity Framework: identify, protect, detect, respond, recover.

Users should be aware that this initiative is in its early stages, so you won’t get pre-configured VMs and the large support provided by the standard version.

Of course, you’re not supposed to migrate your current working environment to Purple right now. That would be a pretty crazy move, as this edition is not yet mature.

However, it’s stable enough to be tested, and defenders will certainly appreciate this new flavor despite the inevitable bugs and oversights.

It’s interesting to see OffSec exploring new fields. The Purple edition is aimed at Blue and Purple teams for defensive security, which means it’s a mix of both worlds, red and blue.

You can get more details about Kali Purple in the official wiki.

Resources for Kali Linux Training

Kali Linux requires effort and time. The key is to practice regularly and to learn from professionals in the field if you want to make it a career. An ethical hacking certification may help too.

The following links could help you unlock many skills:

• Kali documentation
• Kali training
• Hackersploit: penetration testing tutorials
• OffSec: OSCP certification

Bottom Line: Kali Linux

Kali Linux deserves its great reputation as a critically important toolkit for pentesters and anyone hoping to become one. If your organization contains critically important data, whether web-facing or internal, pentesting is a cybersecurity best practice you should adopt to find vulnerabilities before the bad guys do. Kali Linux is a great place to start.

Further reading:

• 10 Best Open-Source Vulnerability Scanners for 2023
• Testing & Evaluating SIEM Systems: A Review of Rapid7 InsightIDR

This article was created by Julien Maury on April 7, 2023 and updated by eSecurity Planet Editor Paul Shread on Oct. 5, 2023

The post Kali Linux Penetration Testing Tutorial: Step-By-Step Process appeared first on eSecurity Planet.

Vendors sometimes use packing to prevent basic reverse engineering or illegal redistribution. Packers basically take the original executable and add a small piece of code called a “stub” to the newly created executable. The stub will then be used to unpack the file and “restore” the executable to its original state.

While some packers like UPX only compress the file, others can also encrypt it.

Attackers can use compression to hide malware inside seemingly harmless and legitimate files, which can fool signature-based detection and even advanced artificial intelligence (AI)-based antivirus solutions. Here’s how hackers can use UPX to render malware undetectable.

Also read: How Hackers Evade Detection

How UPX-Based Evasion Works

UPX can pack a malicious executable and modify its bytes to generate an undetectable version of malware.

Through a self-extracting archive executable, a packer can unpack itself in memory when a packed file is executed.

The packed file is usually smaller on disk but bigger in memory. If you inspect a suspicious file, you might see typical sections like the following:

• UPX0: An empty section that contains no actual raw data but with a huge virtual memory size
• UPX1: The stub and the compressed executable

There are other sections, but we’ll keep it simple here.

When the UPX-packed file is executed, all packed sections are unpacked in memory, including any malicious code a hacker might have stored in it, and the program jumps to the original entry point (OEP) to execute the executable.

Compression Is a Classic Evasion Technique

While UPX-based evasion might seem a bit hard to understand at first glance, compression is a classic approach to avoid antivirus detection.

A simple test you can practice consists of uploading the original and the packed version of a malware sample to your favorite platform — for example, VirusTotal. The packed version is usually caught significantly fewer times compared to the original version of the malware, and many antivirus tools may simply miss the packed version.

There aren’t many statistics about the frequency of UPX use in malware deployment, but MITRE enumerates various “packing-based” procedures adversaries can leverage to conceal their code. Many cases seem to involve UPX.

Detecting UPX-Packed Files

You can try a simple UPX command to spot UPX-packed files:

upx -l {suspicious_binary}

Of course, it’s limited and won’t work all the time. Another limited but still valid option is to dump hex code and search for specific strings like UPX:

hexdump -C {suspicious_binary} | grep "UPX"

You may also leverage portable executable (PE) analyzers to detect UPX-packed files.

Defeating UPX Mangling and Corrupted Files

Many exploits observed in the wild do not rely on UPX itself to unpack the malicious code, generating corrupted packed files on purpose.

The basic example we looked at earlier had very recognizable sections, but it’s possible to alter bytes or insert strings with a hexadecimal editor or another tool to make the file significantly harder to detect.

While such an operation will likely break classic unpacking with the upx -d command and throw errors, the binary will still execute.

Tools like upxdump.py, recommended by Akamai, might be able to fix intentionally corrupted UPX packed files, as it repairs corrupted headers that are frequently used to obfuscate UPX-packed malware.

Be careful, though, as the author warns that some variants simply strip UPX headers or inject null bytes, which would make the tool fail.

Packer Analysis and Anti-UPX Unpacking Techniques

Reversers and malware analysts may use tools like ollydbg, radar2, or even the popular Ghydra to analyze packed files. The critical step is to determine whether the binary uses anti-UPX unpacking techniques or not before proceeding.

While many malware types like Mirai use anti-UPX unpacking techniques such as zero-padded files to slow down security researchers, it does not mean you can’t unpack them. Tools like upx-mod can help you.

That said, the most sophisticated actors could make their files “unpackable” for standard UPX implementations, but that seems pretty rare.

Best Practices for Mitigating UPX-Packed Malware

The use of malicious UPX-packed files shows that you cannot solely rely on antivirus software and other signature-based solutions to catch malware, no matter how sophisticated these tools market themselves.

Without these tools, you’d be even more vulnerable, but attackers will always look for ways to divert legitimate utilities and bypass detection.

UPX is a universal format that can be used to target various platforms, and anti-UPX unpacking techniques can be used to jam reverse engineering and malware analysis.

A good practice is to disable execution, such as tmp and downloads, in some directories when not needed by users, especially in corporate environments, which can be achieved with security policies.

Ensure the system does not hide file extensions, but even if it’s not the case, that does not guarantee that no one will click unwisely, especially with targeted campaigns. You need to log suspicious activities and behaviors.

Read next:

• Top Endpoint Detection and Response (EDR) Tools
• Top Cybersecurity Training Courses for Your Employees

The post How UPX Compression Is Used to Evade Detection Tools appeared first on eSecurity Planet.

Attackers have been using classic flaws for years with a pretty high success rate. While advanced threat actors have more sophisticated approaches such as adversarial machine learning, advanced obfuscation, and zero-day exploits, classic attack techniques such as SQL injection, cross-site scripting (XSS), remote file inclusion (RFI) and directory traversal are still the most common attacks.

These techniques are often the first step on the way to privilege escalation and lateral movements. That’s why developers must sanitize and validate data correctly before processing transactions or saving any entry in a database.

Here we’ll focus on sanitizing and validating inputs, but other elements such as a server’s configurations must also be taken into account to properly secure forms.

See the Top Web Application Firewall (WAF) Solutions

What is the Difference Between Sanitizing and Validating Input?

Validation checks whether an input — say on a web form — complies with specific policies and constraints (for example, single quotation marks). For example, consider the following input:

<input id="num" name="num" type="number" />

If there’s no validation, nothing prevents an attacker from exploiting the form by entering unexpected inputs instead of an expected number. He or she could also try to execute code directly if submitted forms are stored in a database, which is pretty common.

To prevent such a bad situation, developers must add a validation step where the data is inspected before proceeding. For example, using a popular language like PHP, you can check the data type, the length, and many other criteria.

Sanitizing consists of removing any unsafe characters from user inputs, and validating will check to see if the data is in the expected format and type. Sanitizing modifies the input to ensure it’s in a valid format for display, or before insertion in a database.

Why You Should Use Input Sanitization and Validation

The most common techniques used against weak inputs are probably cross-site scripting (XSS) attacks, which involves attackers injecting malicious scripts into otherwise trustworthy websites.

Some XSS attacks are more obvious than others, which means that even if you take the time to sanitize and validate your inputs, a skilled attacker might still find a way to inject malicious code under specific conditions.

A classic attack demo consists of injecting the following script in a weak input, where the placeholder ‘XSS’ is arbitrary JavaScript:

<script>alert('XSS')</script>

If the content of the input is displayed on the page (or elsewhere), the attacker can execute arbitrary JavaScript on the targeted website. The typical case is a vulnerable search input that displays the search term on the page:

https://mysite.com/?s=<script>alert('XSS')</script>

It gets worse if the malicious entry is stored in the database. The demo code might look fun to play with, but in real-world conditions attackers can do a lot of things with JavaScript, sometimes even steal cookies.

When Not to Use Sanitization

The biggest problem with sanitization is the false impression of security it might give. Stripping unwanted chars and HTML tags is only one layer of checking. It’s often poorly executed and removes too much information like legitimate quotes and special chars while it does not cover all angles of attack. You cannot apply generic rules blindly.

The context is the key, which includes the programming languages in use. More on this later, but it’s important to follow a principle called “escape late” (for example, just before output) because you know the exact context where the data is used.

In my experience, the trickiest situations are when you need to allow raw inputs and other permissive configurations. In such cases, it becomes very hard to sanitize data correctly, and you have to maintain a custom whitelist of allowed characters or manually blacklist some malicious patterns.

It’s recommended to use robust libraries and frameworks instead.

More generally, developers must not hesitate to return errors on bad inputs instead of resorting to guessing or fixing, which is prone to errors and flaws.

Best Practices: Sanitizing Inputs, Validation, Strict Mode

There are some principles and best practices that dev teams can follow for the best possible results. We’ll cover the broad categories, along with specifics to watch for.

Don’t Trust User Inputs

Some websites don’t bother checking user inputs, which exposes the application to the maximum level of danger. Fortunately, that’s getting rarer thanks to security awareness and code analysis. However, incomplete sanitization is not a great solution either.

Here are a few of the possible attack paths you need to think about.

GET requests

If developers don’t sanitize strings correctly, attackers can take advantage of XSS flaws such as:

https://mysite.com/?s=<script>console.log('you are in trouble!');</script>

Classic cybersecurity awareness usually highlights the above example with a simple console.log or even an alert. However, it shows that anyone can execute arbitrary JavaScript on your page by simply sending a shortened version of the malformed URL to unsuspecting victims.

Some XSS flaws can even be persistent (stored in the database, for example), which removes the hassle from attackers of making the victim click on something by automatically serving malicious payloads to the website’s users.

Cookies

Websites often use HTTP cookies for session management, customization, and tracking. For example, developers can log in users, remember their preferences, and analyze their behaviors.

The server generates a cookie, or an approximate piece of data, and sends it to the browser to save it for later uses. As a result, stealing cookies allows attackers to be able to impersonate the victims by providing them with immediate access to the targeted accounts without login.

Moreover, hackers don’t have to compromise the victim’s computer. Because HTTP cookies are sent along with each request, attackers can intercept those requests to steal data during man-in-the-middle (MITM) attacks, for example.

A more sophisticated approach can use an XSS attack to insert malicious code into the targeted website to ultimately copy users’ cookies and perform harmful actions in their name.

While Google plans to phase out cookies in its Chrome browser next year, it’s still important to develop best practices for cybersecurity. For example, as of 2022, SSL (Secure Sockets Layer) is no longer an optional layer. However, if the code sends non-SSL requests, cookies will be sent in plain text, so make sure you are using SSL everywhere.

Another good practice is to always use the httpOnly attribute to prevent hijacking with JavaScript. The SameSite attribute is also recommended for developers.

While cookies are convenient for both users and developers, modern authentication and APIs allow better approaches. As storing data in client-side databases allows for many safety and privacy vulnerabilities, it’s better to implement other more secure practices instead.

POST requests

POST requests are server-side requests, so they do not expose data in the URL, for example, when you upload an image on your online account or when you submit a contact form, such as:

<form action="https://my-website.com/contact" method="POST">

A common misconception is that POST requests are more secure than GET requests. However, at most, POST requests are security through obscurity. While it is better to use POST requests for user modifications, it’s not great for security-related purposes, and it won’t harden security magically.

One very simple way to sanitize POST data from inputs in PHP could be through the commands:

filter_var($_POST['message'], FILTER_SANITIZE_STRING);

filter_var('bobby.fisher@chess.com', FILTER_VALIDATE_EMAIL)

Another good practice in PHP is to use htmlentities() to escape any unwanted HTML character in a string.

As with cookies, always use SSL to encrypt data, so only TCP/IP information will be left unencrypted.

Directory traversal

If the codebase includes an image tag such as

<img src="/getImages?filename=image12.png" />

then hackers may try using

https://yourwebsite.com/getImages?filename=../../../etc/passwd

to gain access to users’ information.

However, if your server is configured correctly, such attempts to disclose confidential information will be blocked. You should also consider filtering user inputs and ensuring that only the expected formats and data types are transmitted.

Also read: Top Code Debugging and Code Security Tools

Don’t Trust Client-Side Validation

A common misconception, especially for beginners, is to rely on HTML and JavaScript only to validate forms data. While HTML allows defining patterns and required fields, such as setting a character limit or requiring specific fields to be filled, there is no HTML attribute or JavaScript code that can’t be modified on the client side.

Hackers might also submit the form using cURL or any HTTP client, so the client side is absolutely not a secure layer to validate forms.

Enable Strict Mode

Whenever you can, enable strict mode, whether it’s PHP, JavaScript or SQL, or any other language. However, as strict mode prevents lots of convenient syntaxes, it might be difficult to enable if you have a significant technical debt and legacy.

On the other hand, if you don’t code in strict mode, the engine starts making guesses and can even modify values automatically to make the code work. This opens up vulnerabilities hackers can utilize to inject malicious commands.

For example, in 2015, Andrew Nacin, a major contributor to WordPress, explained how a critical security bug could have been avoided just by enabling strict mode in SQL. He demonstrated how hackers could exploit a critical vulnerability by using four-byte characters to force MySQL truncation and then inject malicious code in the database.

While a simple solution to prevent such an attack would be to execute the command SET SESSION sql_mode = "STRICT_ALL_TABLES" it is impossible to enable this without breaking all websites powered by WordPress.

Consult the OWASP Web Testing Guide

OWASP, the Open Web Application Security Project, maintains a comprehensive documentation called the Web Security Testing Guide (WTSG) that includes input validation.

This guide offers information on how to test various injections and other sneaky attacks on inputs. The content is frequently updated, and there are detailed explanations for various scenarios.

For example, you can check out their page on Testing for Stored Cross Site Scripting to learn how persistent XSS works and how to reproduce the exploit.

Also read: OWASP Names a New Top Vulnerability for First Time in Years

Bottom Line: Sanitize, Validate, and Escape Late

Sanitizing and validating inputs is a mandatory dev practice but you cannot apply a generic solution to all entries. You have to consider the specific contexts to be able to block injections. Moreover, don’t store anything in the database without validating it, but also escape values before displaying them, as some injections can poison database records.

Another essential practice is to escape data as late as possible, preferably just before display. This way, you perfectly know the final context and there’s no way to leave data unescaped.

Lastly, spend time on fine-tuning static code analysis. This process can tend to generate a lot of false positives, such as XSS flaws that can’t be exploited; however, every single HTML attribute and tag that gets its value dynamically should be escaped.

While hackers won’t be able to exploit all tags to grab sensitive data or trick logged in users, you should still incorporate static analysis to prevent as many vulnerabilities as possible.

Read next:

• Software Supply Chain Security Guidance for Developers
• Best DevSecOps Tools

The post How to Use Input Sanitization to Prevent Web Attacks appeared first on eSecurity Planet.

This open-source package is free to download and has several modules for generating hashes from a range of file types, such as Secure Shell (SSH) keys with ssh2john, .kbdx files with keepass2john, and password-protected zip archives with zip2john. You can then use these hashes as input to find the password with John the Ripper.

Pen-testing distributions such as Kali Linux and Parrot OS usually include the full package, so you won’t need additional installations.

John the Ripper can demonstrate how easy it is to reveal weak passwords (and the seemingly more sophisticated ones) using a leaked database and a free tool.

Of course, it’s only one tool in the pen-tester’s arsenal, but it’s particularly convenient to use, and it automates lots of manual operations you would have to run otherwise.

Also read: Top Open Source Penetration Testing Tools

How to Setup Your Test Environment

You’ll need a proper lab to test the command lines. The easiest way is to use a virtual machine with a dedicated operating system like Kali Linux.

There are other installation modes available, for example, on Debian-based machines:

sudo apt-get install john -y

However, you may have to install additional modules manually to crack specific file types, such as zip archives. You’ll also need samples to attack, which are easy to find on platforms such as GitHub, but you can also generate your own hashes.

In terms of hardware, tutorials sometimes recommend large RAM (16GB) and a good graphics processing unit (GPU). But that would be for more advanced uses, so any recent computer will do the job correctly. For our example, we won’t need a powerful machine.

How Does Password Cracking Work?

Before we dive into a practical example, you have to understand the basics of password cracking. The most popular techniques associated with password cracking are brute-force and dictionary attacks. It often comes after stealing critical data, such as databases that contain credentials. In the worst-case scenario, the credentials are in plain text, but most of the time you only get a hash.

Still, if the password is short and/or weak, John the Ripper can crack such data quickly. In general, the time required to crack passwords is directly linked to the strength of the password but, above all, its length.

That’s why experts often say these kinds of attacks are about time and calculation power, but if you don’t secure your passwords, they will be found at the speed of light. Or at least a good GPU.

How Do You Crack Passwords with John the Ripper?

The “john” command has an extensive range of options and flags you can use to run accurate sessions and match the specific format and encryption of your targeted password.

The tool has built-in wordlists that automatically apply by default, but you can specify your own with –wordlist and the path to your custom wordlist.

Using only the built-in features and the MD5 hash of a weak password (not even “123456”), I was able to retrieve the true password in seconds:

echo “4f95578c0f588e028b8e2ea441fc683b” > hash.txt

john hash.txt –format=Raw-MD5

# julien2022 (?)

If you need to crack a password-protected zip, just generate a hash with ssh2john and pass “zip” as the format argument:

john –format=zip hash-zip.txt

It’s the same method with .kbdx databases and SSH private keys. First, you generate the hash, then you pass it to John.

How Do You Secure Passwords Against the Ripper?

The best recommendation to defend against tools like John the Ripper is to have a strong password policy, which means using long and random passwords.

Again, the length is the key. It’s the most critical point you have to check. Unfortunately, bad security policies push users towards predictable strategies and sometimes prevent passwords from exceeding eight characters, but whenever you can, use long strings.

There are security products and open-source modules that can check your databases and force users to use strong passwords and update them regularly. To ease the user experience with all of those complicated passwords, use password managers to autofill credentials.

Indeed, the best password is probably the one you can’t remember, as there are known techniques to build custom wordlists based on famous songs, artists, movies and other elements, including various combinations you might find clever.

Bottom Line: John the Ripper Review

In my experience, John the Ripper deserves its reputation, with far more pros than cons.

Pros

• Easy to install
• Beginner-friendly
• Recommended by professionals
• Supports a large range of encryption and formats
• Intelligence: uses sessions to remember previous results and can detect multiple hash types and salts automatically
• Particularly efficient when combined with open-source wordlists like seclists
• Can be completed with Johnny for those who prefer using a graphical user interface (GUI) instead of command lines

Cons

• The one negative is it depends too much on the results of previous cyber attacks (e.g., leaks, stolen hash)

Read more:

• Getting Started With the Metasploit Framework: A Pentesting Tutorial
• Nmap Vulnerability Scanning Made Easy: Tutorial
• Getting Started with the Burp Suite: A Pentesting Tutorial
• Testing & Evaluating SIEM Systems: A Review of Rapid7 InsightIDR

The post John the Ripper: Password Cracking Tutorial and Review appeared first on eSecurity Planet.

Chenxi Wang of Rain Capital and Andrew Smyth of Atlantic Bridge unveiled the Open Source Security Index last month. The website leverages GitHub application programming interfaces (APIs) to make “finding open-source security projects easier for everyone.”

Anyone can go to the site to discover “the most popular and fastest-growing open-source security (OSS) projects.”

OSS projects are essential in the InfoSec world, but it’s not always easy to find a good and up-to-date list. So having such an index provides a valuable resource for security teams to see the range of OSS projects available for their daily work, and the list also offers a nice overview of the current security landscape.

Also read: The Best Open-Source Vulnerability Scanners

Ranking the Projects

One of the more interesting parts of the ranking is the transparent methodology. The creators ranked entries under six metrics to list the Top 100 GitHub projects:

• The number of times a project has been starred
• The number of contributors to the project
• The number of commits the project has had in the last 12 months
• Number of watchers
• Change in the number of watchers over the last month
• Number of forks

Because the GitHub APIs are pretty convenient and contain lots of useful data, the index can take into account a range of criteria and apply some weighting. For example, the number of watchers is only 5% of the score, while the number of commits the project has had in the last 12 months is 25%.

The index should help promote actively maintained projects. It should also be noted that the number of stars has the highest weight, and represents 30% of the score. For example, at the time of writing, Osquery is behind Sigma, even if Sigma only has 5,805 stars compared to Osquery’s 19,678.

Wang said the ranking excludes bots and anonymous accounts from the number of contributors.

There are also manual additions for projects that lack labels in the GitHub API (tags, topics). The scope is limited to “direct security tools,” which explains why you don’t find projects such as Terraform or Elastic in the ranking.

The Top 25 Reveals Current Trends

Wang wrote in a Dark Reading column that three major trends emerge from the Top 25 OSS projects on the list:

• Attack and red-team open-source tools, such as Metasploit, OSS Fuzz, Atomic Red Team, and Zap, remain popular.
• Cloud computing is now mainstream with security operations, such as Cilium, Trivy, Calico, and Sysdig.
• Automation and as-code workflow utilities like Nuclei and Sigma have begun to emerge.

While open source software does not come without inconveniences, security teams can leverage these popular projects in their strategy instead of developing and deploying with proprietary software.

According to Wang, this is how sophisticated security teams operate these days, by “managing security policies and operations like code.”

Also read: Getting Started With the Metasploit Framework: A Pentesting Tutorial

The Top 5 Languages

At the time of writing, the most popular security projects are written in Python (55%), JavaScript (31.6%), and Go (25.3%).

C and Ruby come in at the No. 4 and No. 5 positions, respectively, at 17.7% and 12.7%.

That’s not surprising, as these programming languages are very popular. Most PoCs (proofs of concept) and demos are written with the same languages.

The Ranking Will Evolve Over Time

The maintainers plan to refresh the data monthly to keep the list current, and it’s an important point. As the security landscape evolves rapidly, many existing lists can be deprecated.

Of course, it’s safe to assume major frameworks such as Metasploit won’t be left unmaintained or abandoned anytime soon, but new security tools could emerge and become popular.

Read next: Best Open Source Security Tools

The post Open Source Security Index Lists Top Projects appeared first on eSecurity Planet.

The researchers reported earlier this month that the VSCode editor could be vulnerable to attacks targeting its extensions. The free open source and cross-platform IDE is very easy to use, and there are literally thousands of free extensions developers can install in one click to speed up their work.

These extensions are usually written with Node, and the packages are downloaded from NPM. which makes common supply chain attacks possible against the code editor. Besides, these NPM packages have their own dependencies, so the breach could come from pretty much anywhere in the chain.

The researchers used masquerading techniques to prove their concept. They impersonated Prettier, an extremely popular extension used by developers to format code: “In just under 48 hours, we got more than a thousand installs by active developers from all around the world!”

Even if not all users fell into the trap, thousands of installs is more than enough to do serious damage, like stealing credentials or exfiltrating confidential information.

Researchers Used Classic Typosquatting

Instead of “prettier-vscode,” researchers used “pretier-vscode,” with only one “t,” in the extension URL on the marketplace. It’s easy to make the typo, and only the URL and a few other details differ, as the researchers were able to use the same logo, the same name, the same description, even an exact copy of the original readme.

If a user typed “pretier” in the search bar, they wouldn’t even get the legitimate extension in the list, as only the typosquatted version has this name.

This approach is heavily used by threat actors on other marketplaces such as NPM and PyPI, but malicious VSCode extensions seem to be on the rise, thanks to its dominant market position.

According to researchers, the danger is high for two main reasons:

• anyone can publish an extension which could be listed in the Marketplace
• all extensions run with the privileges of the user that has opened the VSCode without any sandbox

See the Top Code Debugging and Code Security Tools

Identifying Malicious Extensions

It’s not easy to spot malicious extensions. Look at the screenshot below:

You’ll notice the number of downloads is unusually low for such a prominent extension: 2k vs 27M for the real one. It’s the same for the number of ratings: 2 vs. 370.

However, researchers were able to replicate almost everything else, as display names and titles do not have to be unique on the platform. In addition, the number of downloads or stars could be artificially increased to gain even more credibility.

There are other differences, such as the date of the first release (2022 vs. 2017), but if you miss those details it’s easy to fall into the trap, especially when you lack time to fully vet the source.

Even worse, anyone can get the checkmark “Verified” near to their name just by proving ownership with the domain name of their choice. The term “Verified” could be misleading for many users according to researchers.

All Registries At Risk

The POC looks pretty convincing, but this problem is not specific to the VSCode marketplace. The whole idea with these ecosystems is that anyone can share an extension that can become very popular.

Even if platforms run deep scans to spot viruses and other known malware, nothing prevents an extension from requesting whitelisted (or “not blacklisted”) URLs, such as a seemingly legitimate GitHub repository that contains malicious payloads. These fake repositories get reported and destroyed eventually, but the damage is done.

Researchers also noted that legitimate developers might introduce vulnerable code unwittingly. It’s sometimes hard to distinguish poor code choices from malicious intent.

How to Mitigate the VSCode Threat

It should be noted that this new attack vector has not been observed in the wild yet, which might explain why there’s so little information about it.

The most obvious recommendation for developers is to be extra vigilant when installing any extension to their favorite IDE. Only use trusted sources, but be aware of the common techniques used by threat actors, such as typosquatting and masquerading.

The lack of time excuse is not acceptable in the end. As a developer, you have a responsibility, so it’s worth spending extra time to review your tools carefully.

However, because attackers can leverage other techniques like social engineering to trick their victims into downloading malicious applications, additional measures can help developers to mitigate these threats:

• It’s okay to test a new tool in your free time (in a virtual machine, for example), but not on your work environment.
• Review all requested permissions and capabilities: Why does the program need root access? Is it justified? Are there better alternatives?
• If the extensions need to “run as you,” enumerate your own privileges, and do not hesitate to remove unnecessary permissions if it’s possible. Do you need an administrator account all the time?
• Prioritize sandboxes and other isolation mechanisms: Activate it (it’s not necessarily enabled by default) or install a dedicated package that will confine apps and processes.
• Protect your accounts with MFA/2FA.

Clearly the least privilege principle and containers can help mitigate the threat significantly. For this specific case, users may also leverage “Worskspace trust” and the “Restricted Mode.”

In this mode, extensions might be disabled automatically or have limited functionality.

It’s not magic, though, as it depends on the author’s indications, so it’s unlikely threat actors will “evaluate their extensions for possible security vulnerabilities and declare that they have limited support when running in Restricted Mode,” as VSCode requests.

As a better approach, I would recommend the following to dev teams: Share and discuss new tools or maintain a list of common extensions to install for new members. The good news is that can be scripted and versioned in .vscode/extensions.json:

{
"recommendations": [ "esbenp.prettier-vscode" ]
}

This way, anyone who clones the project repository can install the right extensions automatically.

Read next: How to Prevent Software Supply Chain Attacks

The post Cybercriminals Use VSCode Extensions as New Attack Vector appeared first on eSecurity Planet.

The “private vulnerability” reports announced at GitHub Universe 2022 will allow open-source maintainers to receive private issues from the community. Maintainers will be able to receive reports and collaborate with security professionals and all other issuers to patch vulnerabilities.

Also read: Software Supply Chain Security Guidance for Developers

Code Security in Beta

The new GitHub feature is available in beta version and thus subject to change. However, developers can try it now by going to their repo settings in the “Code security and analysis” section:

The complete documentation is already available and indicates that “Anyone with admin permissions to a public repository can enable and disable private vulnerability reporting for the repository.”

Once it’s activated, the repository gets a new button in the Advisories page:

A Step Forward for Supply Chain Security

The new feature could be a big step towards better security for the entire software supply chain, as security researchers usually struggle to find the right channel to communicate with the maintainers when they spot a vulnerability.

It often ends up in additional OSINT work to find the right social profile to contact or, even worse, a GitHub issue that discloses the vulnerability publicly. According to GitHub, maintainers will get a more consistent experience with a unique and private platform for handling reports and collaborating with security professionals to patch the code.

This should limit the risk of “being contacted publicly, or via undesired means.” Perhaps most importantly, the vulnerability will be “less likely to be in the public eye,” which is critical.

The other expected security features are:

• code vulnerability scanning for the Ruby language is now generally available
• better coverage/security overviews across multiple repositories for organizations

Monitoring Repositories

GitHub also recommends that dev teams monitor repositories for anomalous activities and bad practices, highlighting some of its features like secrets scanning that can spot leaked credentials or the Dependabot technology that helps teams manage security updates.

In addition, developers are strongly encouraged to do the following:

• audit the code regularly (e.g., built-in scanning features like CodeQL)
• enforce 2FA for all org members
• enforce reviews
• restrict collaboration permissions (least privilege principle)
• enable Dependabot for security updates
• secure GitHub actions that are prone to injections, as GitHub uses strings substitution (inputs must be sanitized, using encrypted environment variables, for example)
• revoke unused secrets and tokens
• remove unused dependencies
• avoid secrets whenever possible
• leverage “the continuous improvement approach,” as dev teams can’t be perfect
• share the security responsibility

GitHub is clearly sending a message to developers and security professionals, inviting them to collaborate with better tools and procedures that should reduce misunderstandings and help fix the current broken software supply chain.

These announcements seem to point in the right direction and come after several major initiatives this year to secure the software supply chain that has been the source of major cyber attacks like SolarWinds and Kaseya.

Further reading:

• New Open-source Security Initiative Aimed at Supply Chain Attacks
• Top Code Debugging and Code Security Tools
• CI/CD Pipeline is Major Software Supply Chain Risk: Black Hat Researchers

The post GitHub Adds New Security Features for Open Source Community appeared first on eSecurity Planet.

Whether you’re new to these specialties or an experienced investigator, REMnux contains many helpful Debian packages and configurations to perform advanced tasks, such as:

• Extracting IoCs (Indicators of Compromise)
• Disassembling/decompiling binaries or windows executables (such as PE files)
• Decoding, deobfuscating, decyphering, and decrypting
• Tampering (such as Burp Suite, Thug) and other network analysis (such as Wireshark)
• Investigating malicious code in various platforms (such as Android) and languages (e.g., Python, PowerShell, Java)
• Analyzing memory for code injections and other malicious activities
• Examining suspicious documents (such as PDFs, Microsoft Office, emails)

We’ll examine the pros and cons, but REMnux is definitely a great asset for those who want to focus on their work and skip the “installation hell.”

See our tutorials on Metasploit, Burp Suite and Nmap

Getting Started with REMnux

REMnux can be installed in a number of ways.

The tool is available as a ready-to-use virtual machine (.ova), which means it can run everywhere (Windows, Mac, Linux), but you can also add it directly to an existing system based on Ubuntu 20.04 with the REMnux installer (less than 60 MB).

Be careful if you have a next-gen Apple machine (m1++). At the time of writing, REMnux won’t run on an ARM processor such as Apple M1 or M2, as it’s based on an x86/amd64 version of Ubuntu (source: REMnux documentation).

I prefer using the virtual machine, as it provides an isolated environment and you can save snapshots, which is particularly convenient when you need to analyze ransomware and other sensitive binaries that can literally destroy your system.

So get the OVA image and import it into your favorite software, for example, Virtual Box or VMware.

What Problem Does REMnux Solve?

As the founder and primary maintainer of REMnux, Lenny Zeltser likes to say:

REMnux is for malware analysis as Kali is for penetration testing.

Kali Linux actually contains forensic tools, but the distro is meant for pentesting, and you usually have to install additional resources to perform malware analysis and reverse engineering correctly.

As these resources have their own dependencies, it’s sometimes a bit difficult to make them work properly on a system that is not meant for that, which can be very time-consuming, and sometimes frustrating because of the multiple incompatibilities and dependency conflicts.

See the Best Open-Source Distributions for Pentesting and Forensics

REMnux Pros

• It’s totally free and its components are open source
• It’s beginner friendly and well documented
• It’s easy to install (OVA, docker image, from scratch) and update (thanks to SaltStack technology)
• It’s very popular among malware analysts and security professionals
• The set is very comprehensive, so it’s unlikely you’ll need any additional resources
• Tools are pre-packaged, tested, and pre-configured
• You can use REMnux tools without even installing them, using Docker and REMnux containers

Cons

• The latest big release, at the time of writing, is v7 in 2020
• REMnux is a collection of open-source packages, which on one hand is great, but comes with the same dependency and update issues
• The distro won’t teach you how to master the various tools provided even if the documentation contains useful links and demos

Why Use REMnux?

REMnux is not just another Linux distro for ethical hacking or forensics. It contains pretty much everything you need to perform various analyses.

The added value is the “glue” REMnux uses to make these hundreds of tools work together and remove the hassle of installing and configuring everything by yourself. Those are some compelling reasons to try it.

The post REMnux: The Linux Toolkit for Reverse Engineering and Malware Analysis appeared first on eSecurity Planet.

Kaspersky revealed that APT10, also known as the Cicada hacking group, has successfully deployed the LODEINFO malware in government, media, public sector, and diplomatic organizations in Japan.

LODEINFO has been observed engaged in a spear-phishing campaign since December 2019 by JPCERT/CC. The sophisticated malware was hidden in malicious Word file attachments. So far, nothing unusual for a sophisticated threat actor, but JPCERT/CC concluded that LODEINFO was “under development,” as they found the version number “v0.1.2” during their investigation.

Kaspersky researchers have been tracking the malware since then, and they’ve discovered evidence revealing “high-confidence attribution to APT10.” They observed another spear-phishing campaign in March 2022.

The malicious Word documents contained fake security notices that invited the victims to “Enable Editing” and “Enable Content,” which executes malicious VBA code. Then, attackers were able to infect their targets and set command and control (C2) communications to exfiltrate confidential data.

Again, nothing really new for such attacks. The interesting part is that “the LODEINFO implants and loader modules were also continuously updated to evade security products and complicate manual analysis by security researchers.”

Also read: How Hackers Evade Detection

Can Security Tools Stop Evolving Threats?

The growing trend of jamming investigations is here to stay, and threat actors are now doing professional IT maintenance, with release cycles. Researchers even found an update that skips machines with the “en_US” locale:

In LODEINFO v0.6.2 and later versions, the shellcode has a new feature that looks for the “en_US” locale on the victim’s machine in a recursive function and halts execution if that locale is found.

Evading Windows built-in security systems such as Windows Defender is nothing new and many techniques have been disclosed by security researchers in public POCs (Proofs of Concept).

YouTube is full of detailed tutorials for achieving that, using simple file renaming (e.g., known binaries such as Mimikatz) or obfuscated sequences in PowerShell commands and Python scripts.

Clearly, companies and individuals should not rely exclusively on built-in security. However, the same also goes for antivirus software and other anti-malware solutions.

Of course, it does not mean you should not use those tools, but nothing replaces security awareness training, active monitoring, regular pentesting, and threat hunting. However, even advanced security products and good practices do not guarantee 100% safety, and it’s an endless struggle between attackers and defenders.

However, it would certainly be worse without security professionals, as you can’t fight something you can’t quantify. You need humans to operate these tools and analyze threats and IoCs (Indicators of Compromise). You also need platforms where you can share your knowledge and collaborate with other teams, which sometimes leads to catching APT groups.

Also read: Ransomware Group Uses Vulnerability to Bypass EDR Products

Defense in Depth

Complete security can’t be achieved, especially against global actors or state-sponsored groups. As long as you need employees, you will get spear-phishing campaigns and other social engineering attacks.

There’s also a thin line between security and employees’ privacy rights, but the real problem occurs when the system gets too permissive. Beyond automated scanners and detection tools, the least privilege principle can harden initial access and limit the risk of lateral movements.

Employees can be targeted for several reasons:

• bad practices and lack of security awareness
• bad security policies that push users towards predictable strategies (e.g., weak passwords or common patterns)
• too much permissions or unnecessary root accesses
• disappointment, conflicts with the management

If employees do not need macro-enabled documents, then disallow them (and notifications too) in your office productivity software. Group policies and templates can be used to achieve that globally. If it’s too complicated, cloud platforms usually provide such functionality and the granularity you need.

More generally, if an employee does not need administrator privileges to work, sysadmin should give them a proper role with less permissions. This is basic role management.

If employees are allowed to use “123456” for their password, it’s a major risk. If MFA or 2FA is available but not mandatory, that’s a significant risk too.

In a nutshell, the lack of security culture often shifts the responsibility to the end-users, which can result in painful breaches.

These recommendations might seem a bit paradoxical for such highly-evasive campaigns and skilled hackers who focus on evading malware analysis. However, cybercriminals usually exploit classic flaws to get initial access.

Likewise, post-exploitation may involve a mix of basic exploits and highly technical approaches, so defense in-depth is recommended. In the best-case scenario, the attack will simply fail, but if that’s not the case, you will slow their progression, at least.

See the Best EDR Solutions

The post Threat Group Continuously Updates Malware to Evade Antivirus Software appeared first on eSecurity Planet.

Researchers at the Leiden Institute of Advanced Computer Science have alerted security professionals about risks associated with GitHub and other platforms like pastebin that host public PoCs of exploits for known vulnerabilities.

While such PoCs are usually meant for educational purposes only, researchers found that 4,893 repositories out of 47,300 examined “have symptoms of malicious content,” which represents a bit more than 10% of all PoCs analyzed.

These “proofs” advertised exploits for vulnerabilities that have been publicly disclosed between 2017 and 2021.

See the Top Vulnerability Management Tools

Signs of Malicious PoCs

To determine whether the repository is malicious or not, researchers used specific criteria:

• they checked whether the PoC’s publisher IP is in popular blocklists such VT or AbuseIPDB
• they checked whether the hash of the provided binary and exec got flagged by Virus Total
• they analyzed obfuscated code (hexadecimal, base64).

They discovered info-stealers disguised as legitimate PoCs, obfuscated Python script in PowerShell commands, and inactive malicious components that could be activated by the author.

Some repositories seem to contain RATs (Remote Access Trojans) such as Houdini, or unexpected requests to command and control (C&C) servers (e.g., Cobalt Strike).

Also read: Cybersecurity Agencies Release Guidance for PowerShell Security

Hijacking Legitimate Tools

Cybercriminals diverting legitimate tools to fool unwise testers is nothing new, and I’ve found that out in my own work.

I created a repository some time ago that demonstrates how easy it is to fool beginners in cybersecurity. The code does not contain any malicious code like external requests, but it would have been easy to add, especially in Python.

Black hat hackers sometimes use GitHub and similar services to host malware, as it allows them to evade most detection tools. It’s a known tactic that is hard to offset, as many teams use the same platforms for legitimate purposes.

However, running code blindly without knowing what it does is the very definition of a script kiddie. The problem is that security professionals can be tempted to act recklessly in an effort to speed up their operations.

How to Avoid Malicious PoCs

The obvious but still valuable recommendation is to check any code before running it on your machine, especially when it’s for an exploit kit or ransomware.

If the code is too obfuscated, it’s a warning sign. Of course, obfuscation is often mandatory when building exploit code, but testers should take the time to deobfuscate it and understand what it does exactly.

Leverage powerful platforms such as Virus Total and other databases to check your samples and executables.

In addition to this, testers should absolutely get an isolated environment. It’s way easier these days to build a lab, for example using a virtual machine and a dedicated operating system like Kali Linux.

Most security experts recommend using separate environments for sensitive activities and daily tasks.

Of course, your machine will likely use the same network for external calls, so ensure you don’t use your real IP (e.g., by using a VPN) and you don’t share too many permissions and folders between the virtual machine and your default system.

Having a dedicated machine for sensitive operations might seem a bit expensive, but it makes sense from a security perspective.

Last but not least, if you cannot determine whether the PoC can be trusted, then ask for help or read notes by other professionals in the community. Binary analysis requires deep knowledge and the appropriate tools.

See the Best Vulnerability Scanners

The post Cybercriminals Use Fake Public PoCs to Spread Malware and Steal Data appeared first on eSecurity Planet.