AccessData is the first forensics company to offer a full-featured API that can integrate across the entire forensics and e-discovery portfolio, dramatically speeding up investigations and reducing the risk and expense of passing data between platforms.
AccessData recently teamed up with CyberSponse, a leader in automated incident response playbooks, to demonstrate how the API would work to automate incident response analysis. In this video, Joseph Loomis, CSO, CyberSponse and Steve Sunday, Principal Technical Engineer, AccessData show how, with the new API, a forensic collection job in AD Enterprise is kicked off almost immediately when a possible threat is detected, and how that evidence is then accessible in AD Enterprise for root cause analysis.
Joe: What you’re looking at right now is the CyberSponse platform itself. As an incident responder, you’re going to spend most of your life either in the Alerts, or Violations, or Incidents page.
In the Alerts page — what I’m going to do is I’m going to generate a simulated alert where you have an asset that’s been critically infected and you need to do something with AccessData in order to capture the memory. And so with that I’m going to go down and I’m going to run a simulation of AccessData [mumbling].
So when I run that, you’re going to see it creates a new alert at the top, where there’s a successful inbound connection. What this does is it creates an alert of an unknown… a specific port, 31337. And that is specifically because you’ve got a connection coming in, inbound to a specific asset.
And we can look at it down here in the asset records: it’s the CEO’s laptop of the organization.
Well that’s a pretty important connection that you see, that’s happening on your network, that you might have to respond to. So all we have to do in the automation world, if we want to remediate or get a capture from AccessData, is I highlight that asset and I execute a full-access memory [capture].
And what you can see happening over here on the right-hand side is that AccessData is actually running Playbooks in the behind-the-scenes — and I’ll show you those in a second — that actually captures and communicates with AccessData Enterprise; captures the memory of that actual laptop itself. Steve, following my demo, is going to be able to show you that.
And so what you can see is that the assets are correlated to the events, to the hunts, to the incidents, to the vulnerabilities, around this specific alert that came in. That’s where your ability is to interface with all of those other products that we talked about.
So it’s curious: what does that Playbook do, and what did we do today?
So what I’ve done is, if I view executed the Playbook option inside the incident alert record, I can see added comments relayed at the outset, I’ve waited ten minutes, I’ve been able to grab a second comment, and I’ve been able to execute a specific asset. And I’m opening a page right now, which is the Playbook engine.
And that Playbook engine is exactly what ran behind the scenes, and I’ll take you through this real quick.
By creating that trigger, I created it and I ran the AccessData, and I created a case around AccessData. I added a comment to the record; I added a related asset which is the CEO’s laptop; I waited ten minutes for it to get ready to communicate and build the connection between the two; I executed the volatile memory acquisition; I added a second comment to the record that the acquisition took place; I got the job status back from AccessData; then I added the volatile data to the case that I had retrieved from AccessData itself; and then I added a completion comment.
So what you can see is all the red icons is where we actually automated and integrated with AccessData, in order to automate the forensic aspect of it. The value of that is you no longer have to jump between products anymore. You can execute and control, almost like a remote-control console, all the executables that need to take place in order for you to capture that data within the incident response record.
And so those Playbooks — like I said, if you want to do further more investigation with that, you can add more approvals, you can add more steps, more connectors to more products. You can take that memory capture, do further evidence or collection data or scanning with it, as well, or extract specific indicators of compromise from it; you can do that all through using the platform itself.
And with that, I’m going to let Steve take over from his part.
Steve: What Joe just showed us was the automated Playbook, and the data that was grabbed using AccessData Enterprise. What I’m going to show you is the data in the AccessData GUI, so we can actually view it.
He grabbed — in that Playbook, there was an incoming connection on port 31337. And so we’re going to go ahead and take a look at the sockets that we grabbed, and we’re going to see the connections.
What we can see here is the CEO’s laptop, and we can see here the established connections, and I can see right away, there’s 31337, there’s an active connection [indecipherable] .43, and there’s an active connection from 10.1. If we go to this in Notepad, we can see the process ID, and the date and time that it happened.
So now that I know that that’s there, I can go up into the processes and look at it, and see the active processes that were running… and we’ll find somewhere in here is my Notepad; we’ll see that Notepad is actually running on this [indecipherable]; and if we look at the command line of it, the command line looks like a Netcat listener, so it’s -L, so it’s listening on port 31337, executing a command line.
So the command is right underneath it, so we can see the parent ID is the same process ID of the Notepad, so we definitely know that we’re tracing of this command prompt. And Notepad did spawn that.
So what we also can do, is take a look at all the network drivers and the users on this machine. And this is all the information that it grabs, so we can open files and the DLLs.
On top of that, what I’ve done is, I had a scan of the CEO’s laptop, so I can do a comparison from Scan A and Scan B.
So this is a scan prior to anything happening, so I can left click and then right click, and I can get a quick [delta] of new processes that showed up from Scan A to Scan B.
So we can see right here, here’s my Notepad that showed up, and we can see the same command line right there, and there’s the cmd.exe, looks like it’s running in the Downloads directory: my user path, Users\Steve\Downloads\cmd.exe, and it looks like it’s running Notepad as well.
I also can get new connections on here, too. So if I can compare the two scans, same type of thing: anything in red shows up that’s new. There’s my 31337, running my Notepad, and definitely we know we’ve got an issue.
So from here, because I’m in the GUI, I’ve already done this in the interests of time, I’ve gone and loaded a preview of the machine.
So from here, I can look at all the files on the machine; I can scroll down through them, there’s a hundred and twenty-something thousands on the box. I can scroll down through them, I can do a timeline, I can do all kinds of different stuff with these files.
I can get all the properties; I can just click on one of them and it’ll give me the properties of the file, and I can offload the file… I can kill it if I needed to, the process.
And on top of that, we know we have some executables on here that are bad. So what we can do is do a remote search on the box; we know we have a Notepad running, and I can create an XML template to look for these files being hashed.
Because I had the processes; I know what the hash is; and if I open this up, you will see here, here’s the hash galley, the XML, like I showed you when we created this, and it’s an executable file.
So if we just clicked Search on that, it would go through on that remote [indecipherable], and even things I have listed up here, it will search for that.
Once it finds it, it will come back, and it will show us the machines, the different files that we found.
So not only did we find my Notepad here, down at the very bottom on that box, we can see that that’s running out of my own directory, my user downloads directory; we can see that there is a Netcat list, running out of the administrator’s directory, there’s a Netcat on here.
And the key is that there’s a bunch of files, and even here in the recycling bin we’ve found a couple of files that were deleted, that the hash value actually matched up on that.
So then we could go back over to our processes, under the volatile information, and I could kill one of these processes. So if I take a look at the process, I could run a… if I click on the process then I could kill it, or I could wipe it, and I could add it to the hash values, if I wanted to.
On top of that, while we’re in here, I ran a module called System Information, which is where we’re going to glean the kind of information for ourselves, for our infected node. It’s going to pull all the apps, it’s going to grab all the prefetch files, so I can come here and take a look… you know, the prefetches, where all the different things are; I can get my user assist files; downloads; URLs; network connections; the shares on that box — so we can see if anything else was opened up on it — jump lists; shortcuts on the machine; I can pull the users onto the box; I can parse out my shellbags on the machine; also it can grab USB information. And that’s all in one nice little GUI.
Then we can export. Same thing with the volatile data, I can export any of this information that I needed to.
So also, while we’re doing a preview of it, we can do a lot of things like, you know, I can go and do searching… I can look for prefetch files. I can filter in on a prefetch file, I can find my command line that was executed and look at it in its natural format.
And there we go: looking at this one here, we can see that this is coming out of Steve’s under Downloads, and it was executed this afternoon, or when the alert happened.
I can go down and grab the registry files, I can do a timeline on it, see all the machines and anything that was accessed in the last couple of months, last couple of days, couple of hours, by simply creating and writing filters.
So to cut a long story short, Joe’s system, CyberSponse, got an alert; created an asset through the Playbook; went and used AccessData through the APIs; grabbed all the process information, and the service information and all the volatile data, we’re able to see that we definitely do have an incident, we’re able to investigate it, and remediate it.
Joe: And that time to respond is where you’re going to get a lot of value, right? As it’s doing a memory capture that takes a few minutes, you’re saving time by executing it remotely before you have to go back, before you go into AccessData Enterprise in order to look at the data itself. So you’re getting ahead of the curve, so to speak: you’re able to streamline your process.
It’s interesting when you start to automate things: you know how you saw I manually executed it? You can start automating when those executions take place so that you don’t even have to have human intervention. You literally could say “Every time that there’s a known compromise on an end point, automatically grab the memory or drive image of that device, before you even open the alert.”
So that’s kind of a proactive response that you can’t currently do… that you couldn’t do with any other product combination yet today.
Steve: Yeah, and you can pass the API’s variables from [the] CyberSponse system. So if you had a specific file name, or something like that, you could go and grab it. You could use the API to grab the individual file; you could do a full disk dump, as Joe said, a memory dump, including the [indecipherable] file; volatile data….
A lot of the stuff we can do manually in the GUI, we’ve automated to be able to make those response times a lot faster, and almost instant.
Learn more at accessdata.com/products-services/api