In this demo, Spencer Engleson, security solutions engineer, runs through a common phishing maldoc attack scenario to show how InsightIDR enables you to detect and contain threats.
Hi there, and welcome to this demonstration of containment in InsightIDR. My name is Spencer Engleson, I work on our security solutions engineering team, here at Rapid7, focusing on our threat detection and incident response line of products and services. And, today I'm going to take you on a brief demonstration of how InsightIDR can not only detect and point out compromise, but also contain it, by killing malicious processes, quarantining affected assets, and disabling user accounts. So, let's get to it.
What I'm going to share with you today, is a scenario based off of a very common phishing attack. In this case I have a Metasploit instance, which I'm going to use to compromise this Windows 7 victim machine. On this victim machine, you'll see this invoice, this is a malicious Word document that our fake user is going to open to establish a session back to that Metasploit instance. And lastly is my instance of InsightIDR. I do have an agent running on this Windows machine, so we'll see some alerts come through in InsightIDR, I'll be able to take containment actions directly from the resulting investigations.
All right. So, I'm using a handler on this Metasploit instance. Which is going to start a listener for a reverse TCP connection, that is coming back from this malicious document. So as I open this, we should see a session open, and we do. Just to prove this is a legitimate session on this machine, you can see I'm running as the username Ryan. Rusty Ryan is my user here. And what's happened, is in the background here, I have a couple of malicious embedded macros that run automatically at the start up.
When this word document opens, these macros execute and call back to my Metasploit instance. Now, we should get an alert in InsightIDR for that word doc executing, the malicious word document executing, that is. But I'm actually going to go ahead and escalate privileges in this session to get system level access as well.
So, we're going to bypass user account controls. And as you can see I'm still in user space, but now I should be able to run and get system command. And we are now running at system level. So if I background this, to go look at my sessions, 'cause you can see I have two different Meterpreter sessions running here, both on the Windows 7 S4 machine. One is in the username space, Rusty Ryan, that original user who opened the word document, and second is our system level shell. Who we accomplished by escalating privileges.
Now, here in InsightIDR, we should see a couple of alerts come through momentarily. One for the initial maldoc execution, and the second alert for that malicious privilege escalation activity, and as you see here, we already have an attacker behavior alert that's fired. And this is based off of malicious document execution. So in our evidence panel here, we'll see more details, this first alert is because InsightIDR has identified processes being launched by Microsoft Word from the user's directory. It's just not how Microsoft Word typically executes. And, this is part of a larger threat, where we're tracking maldoc behavior.
Our second alert is based off of the file name, where we've actually identified the invoice number 12345 naming convention as very common in malicious document phishing attacks. Now in our actual source data, we'll see evidence of this malicious macro executing, that's this process name here, and you'll see that this is running out of the user's directory.
And, we'll see that this is a child process of the parent winword.exe.
Now, I'm not going to try and pronounce this process name, but if I go to my Windows instance and pull up task manager ... we can actually see that process running on this machine as well. And, this is the process that this first Meterpreter session is embedded in. So, we're actually going to use InsightIDR to go ahead and kill this process, and we'll see that first Meterpreter session die.
So, right here from our investigation in InsightIDR, I'm going to say, "Let's go ahead and take an action. Let's kill this malicious process." As you can see, I can actually choose from the affected processes here, I'm going to specifically kill ... this one. And I'm actually going to see if I can switch these, I'm going to see if I can show you both screens, so we can see both the process die, and my Meterpreter session time out or die.
And there it goes. Malicious process just died, and there goes our Meterpreter session.
Now, obviously do still have that second Meterpreter session, in the case that an attacker's able to interact with a session pretty quickly, they may be able to migrate their session into a different process, or they could do what I did, where you're able establish a second session of higher privileges on the box.
So, our next step here is going to be to fully quarantine this asset. Right? We've killed that one malicious process, but there's still reason to believe that this system may be further affected. In this case, it decidedly is.
So, back in InsightIDR, I'm going to take one more containment action for this particular asset, and that's going to be quarantined. And again, InsightIDR highlights these options for me. And in this case, since we're quarantining, rather than killing a process, we won't see our session die quite as quickly, it's going to time out rather than terminate altogether. But, we should see I will be unable to access the internet on my Windows machine here.
And there you have it, my internet access is blocked, I can try to get to Google, Facebook whatever, I'm not going to be able to get out. We are quarantined. 'Cause then if I try to interact with that session. Oh! You can actually already see, the session has died.
All right, well now that we've contained the immediate threat, I wanna take one more action, and that's disable Rusty Ryan, our affected user. So, I'm going to add Rusty to our investigation here, and we're going to take one more action. We're going to disable this user in Active Directory.
Now, this workflow's going to give me one more step. Since, you'll notice disabling a user falls under a workflow, rather than a native Insight agent action. So, we're actually orchestrating with, in this case, Microsoft Active Directory LDAP, and what's going to happen, is InsightIDR is going to call LDAP and look for this particular username, and then confirm that it's identified the correct user.
So, we'll see I actually have a human decision to make, and there it is, a human decision. Where InsightIDR asks me, "Hey, are you sure this is the individual that we would like to disable?" And, I'm going to go ahead and say, "Yes." And I will back to my investigation. And, as you can see, we had those malicious processes come through.
And, we should see the end of that user containment workflow. And, there it is, user is disabled. Just to prove that went through, I'm going to pull up my Active Directory instance. There you go, as you can see this little down arrow indicates Rusty Ryan is disabled.
I'm going to go ahead and re-enable them here. We have no active sessions, we have a full chain of our historical artifacts, telling us exactly who did what within InsightIDR. And we've successfully contained this threat.
