In the spirit of Halloween, I’ve decided to demonstrate how a hacker might go after your company, via the full “kill chain.” (Muhahaha!)
Ok, it may not be that scary (or as scary as the picture above), but the blog below is a little taste of cyber “horror” to demonstrate what goes through hackers’ minds during an attack.
All of what’s written below is a fictionalized first-person account of a hacker (and, no, he’s not wearing a black hat and mask in front of his computer, and, no, he’s not really the Grim Reaper, either. It is, after all, Halloween. Let’s have some fun. Happy Halloween!)
Kill Chain, Step 1: Reconnaissance
The first stage begins with studying your enemy. You have to figure out what you can learn from open source methods, from social engineering, and maybe even a little guessing. In fact, the entire kill chain (an entire operation) could actually just be information gathering for the reconnaissance stage of a larger campaign.
I’m going to explore open source information available on the Internet, using places such as Facebook, LinkedIn, Twitter, Google Plus, your company site, articles, and whatever I can get my hands on that allows me to learn about your people, processes and technology.
I’ll combine this with some social engineering and possibly, depending on geography, some physical monitoring and “scoping out.” Finally, I’ll look at your Internet-facing services for open ports and services that might be a juicy target.
Kill Chain, Step 2: Weaponization
Based on what I gathered during the reconnaissance phase, I’ll go to my toolbox and find relevant exploits, rootkits, Trojans and utilities. If I am unsure of what technology you have deployed, I’ll stick to the most common stuff—targeting Windows XP or Windows 7, Acrobat, Java, Internet Explorer, etc.
I’ll look for stolen or hard-coded credentials for any known services that you’re running, such as remote login services and fixed-function devices that have standard passwords. I’ll plan my weaponization stage around anything interesting I 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.
I take my malicious PDF and insert instructions saying that once it executes, it will connect back to my Twitter bot where it will receive further instructions.
Kill Chain, Step 3: Delivery
It’s time to deliver my payload. Knowing that everyone likes a new friend, and knowing that your CEO gave a keynote speech at a conference yesterday, I find my target—the CEO’s assistant.
I send a LinkedIn request to the assistant asking him or her to visit my LinkedIn page. I even say, “I know you probably don’t open attachments, so please visit my page and download my resume from there for the open position we discussed at the Cyber Defense 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).
Kill Chain, Step 4: Exploitation
The target downloads the PDF, opens it in Acrobat (we know how hard it is to stay fully current on patching), and my shell code executes.
Kill Chain, Step 5: Installation
I made 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. I name my spawned child process acroupdater.exe to try to blend in.
Kill Chain, Step 6: Command & Control
My executable connects to my 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). I 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, so I’ll describe my actions in the next section.
Kill Chain, Step 7: Actions on Objectives / Data Exfiltration
Ok, so I have one set of valid credentials but it is just a local administrator and domain user account, but not domain admin. I want more credentials. I tell my payload (via my Twitter bot) to pull down WinZip to the local machine.
I’m trying 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. My technique works and, after about an hour, a system administrator was told that WinZip was installed on that machine and thought that 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? I have his password hash in memory and I send that back to my bot to lookup via rainbow tables to figure out his credentials. I now have domain admin privileges! Excellent!
Now that I have valid credentials, the payload that I had dropped looks around at the network and finds ‘backup-domain.mycompany.example.’
I instruct the payload to use my newfound credentials to remotely log in to the backup domain controller. Once I land there, I see that putty.exe is there as a tool for remotely logging into other machines that are running SSH. This is excellent. I 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, I 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.
I create a few new local user accounts and set up some scheduled tasks to re-establish the ssh tunnel in case it goes down. I 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. I then tell my original payload to terminate and self-delete as I have live, remote access and am now “living off the land.”
I start looking around at hostnames, IP-addresses, and services that are visible inside the enterprise. I continue to gather information that will help me persist in case my main access point, this backup domain controller, is taken offline or I am otherwise detected.
I 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. I do as much as I can with few new binaries, and I make sure to put some sleeper agent binaries that will communicate back with me in 30, 60 and 90 days but will not perform any actions or communicate until then.
From here I extract the CFO’s credentials and, guess what? I log directly into Outlook Web Access! Silly, why didn’t they have two-factor authentication?
I know the relative location of headquarters, so I make sure I 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 I’m in, I immediately download every email and attachment I can get my hands on. I’m collecting a lot of information now, with a lot of juicy financial spreadsheets and corporate roadmap documents.
I login the same way to accounts owned by the CEO, the VP of engineering and others.
This is fictional, but the actions and processes described above are meant to be realistic. You can see how, depending on your environment, your vulnerabilities, and your 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.
The post Halloween Special: Inside a Hacker’s Mind During the Cyber “Kill Chain” appeared first on Carbon Black.