All postsSecurity testing needs to be more realistic and subtle than just running malware
Your own network can provide everything that an attacker needs to achieve its goal. In many ways it’s impossible to tell the difference between an effective attacker and a good systems administrator.
It’s said that carrying a weapon increases the chances of being hurt by that same weapon. The same goes for keeping potentially harmful, unneeded tools on your network.
An attack usually involves gaining some level of access, perhaps achieving persistence and creating, damaging or downloading data. You can do all those things, on purpose or accidentally, as a legitimate sysadmin using the tools built into Windows. Similar tools will exist on other parts of the network too.
Not exactly The Matrix
It makes for more interesting headlines to recount stories of elite hackers. They use specialised malware and arcane techniques to weave magic, Hollywood-style. But an attack can often be as simple as a phishing email. That’s all you need to extract login details. You then use those details to log in.
If the attacker captures the right account it could be game over already. If you have the CEO or CFO’s email account under your control you can use effective social engineering to extract data or money. You don’t need technical ‘hacking’.
But technical hacking might be needed in some cases. An enterprise or small business network can contain all the ingredients an attacker needs to infiltrate systems, establish a long-term presence and steal or damage data.
You can even create a ransomware attack using just the tools built into Windows.
If you can access a user’s files you can encrypt them using a variety of legitimate tools. Some of these are built into Windows. Even something as simple as the 7zip archiving program or GPG encryption package works effectively.
Here is what a very basic, hard-to-detect ransomware attack could look like:
C:\Users\Fred>gpg -c -o oops.docx.gpg Important.docx && echo "Send Bitcoin to …" > "C:\Users\Fred\Desktop\README.txt"
The attacker is using the free GPG encryption software to encrypt an important Word document called Important.docx. She then creates a text file on the Desktop called README.txt. Inside this text file is the ransom demand.
This is not exactly up to the exciting style of the sci-fi hacking movie The Matrix. But it works, which is why real-life criminals do it.
Why live off the land?
There are distinct advantages to this approach, for the quiet attacker. There is an entire, multi-billion-dollar industry built on detecting malware. Malware is a term for malicious software. It can relate to viruses, worms or more likely these days, back doors – otherwise known as Remote Access Trojans (RATs). Many malware files are known files or files that contain significant clues that security products detect.
If you use a known tool to hack, there is a high chance a security product will detect your actions. If you use PowerShell the chances are much lower. Some security products detect specific malicious behaviours, but they might ignore tools used by systems administrators. This is due to the risk of interfering with legitimate work tasks.
Some real-life examples
To use the ransomware example above, consider the two following scenarios. We have used both in testing and other (legal) engagements:
Incident #1 – the ‘technical’ hacker
The attacker exploits a known vulnerability in the target, using a malicious PDF sent as an email attachment. She then uploads malware in the form of a widely used ransomware encryption program. Executing this file, the attacker encrypts the hard disk and issues a demand for payment (a new text file on the Desktop) in return for the recovery key.
Incident #2 – the resourceful hacker
The attacker impersonates a member of the IT team, calling the target on the telephone and extracting their login credentials. She then logs into the target and uses PowerShell to encrypt the user’s files, issuing a demand for payment (by email) in return for the recovery key.
Ransomware is a payload
A typical cyberattack includes different phases, these being to run reconnaissance, gain access, escalate privileges and steal or destroy information. Establishing persistent access is optional. This is all quite straight-forward and predictable. Which is good news for defenders. It is also largely possible with built-in tools, which is less good.
In a ransomware attack the ‘steal or destroy’ stage above is where you would run the program or script that encrypts the victim’s data. Everything up to that point is the same, whether your intent is to start a ransomware campaign, spy on the organisation silently or use the compromised system as a steppingstone to another network.
The message here is that if you can detect malicious intent anywhere in the attack chain prior to ransomware being run, you stand a chance of defeating the attack. Ransomware is just a payload in a longer series of events. In that respect it is not to be feared as some special ‘magic’ attack. The consequences might be obvious and significant, but in some ways it’s less serious than a more subtle attack that silently steals or corrupts data over a period of time.
Testing the landowners
Security tests, such as those conducted by well-known labs, often focus on known malware. Sometimes, if you’re lucky, they will use the same tools that the more flexible hackers use. That way you can gain a sense of how effectively security products detect attacks from a range of attackers. There will be the low-skilled and the more resourceful ones. But a thorough test will take into account the legitimate tools commonly found on networks and (ab)use those too.
In one example, a botnet abusing ‘internet of things’ (IoT) devices, the attacker gained persistence using standard Linux methods of starting services every time the system started up. In this case Mozi made entries in /etc/rc.d and /etc/init.d. It also created related startup scripts in /usr/networks and /etc/rcS.d. For the non-Linux readers, these are very normal ways to ensure programs start every time the system restarts. It also explains why Linux is not yet the Desktop choice of most…
Organisations don’t need all of the tools available, all of the time. And they don’t all use them the same way. Leaving things as ‘default’ creates higher risk, as you’re effectively leaving break-in tools scattered around your property. For those tools deemed necessary, configure third-party security tools to allow only the types of tasks you think you’ll need. It’s better to unlock a feature when requested than to allow everything and suffer the consequences of a breach.
