CIO

​Understanding cyber attacks from a hacker’s point-of-view

By Kane Lightowler, Managing Director Asia Pacific + Japan, Carbon Black

“Know your enemy and know yourself and you can fight a hundred battles without disaster”—Sun Tzu

Security professionals love to quote Sun Tzu. It can help to change the way security is approached. Next-generation security is about evolving beyond simply block-and-tackle techniques towards understanding the root causes behind cyber attacks. By better understanding how attackers operate, we can be more effective defenders.

Introducing the cyber kill chain



A few years back, Lockheed Martin applied the military concept of a kill chain to cyber security, in a model known as the cyber kill chain.

It describes the different stages of a cyber attack from the perspective of the attacker, with the idea that detecting and disrupting any one stage can prevent the entire attack from succeeding.

Understanding how cyber attacks work can enable a CSO to focus on addressing attack delivery mechanisms (e.g., with URL and email filtering), preventing exploitation (e.g., with patch management), and using network analysis to look for signs of command-and-control.

If an attacker reaches the kill chain’s installation stage, he/she has already penetrated the organisation’s defences and may do so again at will.

By the time IT identifies a piece of malware, without further context they will not know whether an attacker has moved on to later stages.

The attacker may have dropped other software, made configuration changes, stolen user credentials or exfiltrated critical information.

Looking for signs at all stages of an attack enables detection of intrusions faster and earlier, and enables IT to focus on early preventative measures instead of just clean-up. Most malware is simply a means to an end for an attacker. Processes and technology provide the larger picture.

A cybercriminal’s viewpoint

Step 1: Reconnaissance

As a cybercriminal, you begin by studying the target. Assess what can be learned from open source methods, from social engineering and maybe even a little guessing. The entire kill chain could comprise information gathering for the reconnaissance stage of a larger campaign.

Explore open source information available on the Internet, using Facebook, LinkedIn, Twitter, Google Plus, the company site, articles, and anything that enables you to learn about the target company’s people, processes and technology.

Combine this with some social engineering and possibly physical monitoring and ‘scoping out’. Finally, look at the Internet-facing services for open ports and services that might be a juicy target.

Step 2: Weaponisation

Based on information gathered during the reconnaissance phase, you go to the toolbox and find relevant exploits, rootkits, Trojans and utilities. If unsure of what technology is deployed, stick to the most common apps—targeting Windows XP or Windows 7, Acrobat, Java, Internet Explorer, etc.

Look for stolen or hard-coded credentials for any known services that are running, such as remote login services and fixed-function devices that have standard passwords.

Plan the weaponisation stage around anything interesting found in the previous stage, like if particular employees are attending a conference—that makes for good content to put in phishing attacks or to use for later social engineering activities.

Take a malicious PDF and insert instructions saying that once it executes, it will connect back to a Twitter bot where it will receive further instructions.

Step 3: Delivery

Time to deliver the payload. Knowing that the CEO gave a keynote speech at a conference yesterday, find a target—the CEO’s assistant.

Send a LinkedIn request asking him/her to visit a LinkedIn page. Even say, ‘I know you probably don’t open attachments, so please visit my page and download my resume for the open position we discussed at the Cyber Defence Conference yesterday’.

This might not work, but the link brings the individual to a site that looks like LinkedIn, but has a URL that’s just a little different. Let’s assume this works (as phishing is still, sadly, very effective).

Step 4: Exploitation

The target downloads the PDF, opens it in Acrobat and a shell code executes.

Step 5: Installation

Make sure a PDF with a resume is actually opened, despite the exploitation going on behind the scenes.

A payload is dropped and executed and it is signed with a valid (but stolen) digital certificate from a small software company that didn’t properly protect its code-signing certificate.

Name the spawned child process acroupdater.exe to try to blend in.

Step 6: Command & Control

An executable connects to the cyber-criminal’s Twitter bot using SSL on port 443 and starts sending encrypted data (hostname, IP-address, user account, hashes of all available user accounts on that machine, process list, and directory listing). Use rainbow tables to quickly look up the plaintext values of the password hashes.

This stage and the next stage essentially go hand-in-hand.

Step 7: Actions on Objectives / Data Exfiltration

You have one set of valid credentials but it is just a local administrator and domain user account, not domain admin, so you need more credentials. Tell the payload (via a Twitter bot) to pull down WinZip to the local machine.

Try to get someone else to log in to inspect this machine, but not detect (or feel) that the machine is compromised such that it gets pulled offline or reimaged.

This technique works and, after about an hour, a system administrator is told that WinZip was installed on that machine and thinks this was strange.

He logs in and starts looking around but doesn’t notice anything detected by AV or in the Windows Event Logs.

As soon as he logs in, guess what? You have his password hash in memory and can send that back to your bot to lookup via rainbow tables to figure out his credentials. Now you have domain admin privileges! Excellent!

The payload that you had dropped now looks around at the network and finds ‘backup-domain.mycompany.example.’

Instruct the payload to use those new-found credentials to remotely log in to the backup domain controller. Once you land there, you see that putty.exe is there as a tool for remotely logging into other machines that are running SSH.

This is excellent. Tell the payload to open an ssh tunnel outbound to port 443 to my fake website, kids.charities.example.

Once the ssh tunnel is established, run Microsoft Remote Desktop (RDP) to communicate back through the tunnel and use the legitimate credentials to log in to that backup domain controller with my hands-on keyboard.

You create a few new local user accounts and set up some scheduled tasks to re-establish the ssh tunnel in case it goes down.

Dump the entire active directory set of users and their credentials and copy and paste the text via RDP so there are no additional outbound sockets created.

Then tell your original payload to terminate and self-delete as you have live, remote access.

Start looking around at hostnames, IP-addresses, and services visible inside the enterprise. You continue to gather information that will help to persist in case your main access point, this backup domain controller, is taken offline or you are otherwise detected.

Make sure to spread to other systems within the environment, trying to target backup systems, staging systems and places that are neither very active nor closely monitored.

Do as much as you can with few new binaries, and make sure to put some sleeper agent binaries that will communicate back with you in 30, 60 and 90 days but will not perform any actions or communicate until then.

From here extract the CFO’s credentials and, guess what? You log directly into Outlook Web Access! Silly, why didn’t they have two-factor authentication?

You know the relative location of headquarters, so make sure to login via a jump box that is in the same city in case they are looking at the geographical source of the login attempts (unlikely but I want to be as safe as possible).

Once in, you download every email and attachment you can. Collect lots of information now, including juicy financial spreadsheets and corporate roadmap documents.

You login the same way to accounts owned by the CEO, the VP of engineering and others.

All this is fictional, but the actions and processes described above might well be real. Consider how, depending on a target’s environment, vulnerabilities, and security posture, a malicious actor can quickly access very sensitive data.

Continuous monitoring, not allowing new binaries, using two-factor authentication, and employee awareness are all critical in today’s age of constant cyber threats.