 Hello, DDA Stevens here, Senior Handler at the Internet Storm Center. Brett Duncan posted another malware traffic analysis post on his site, and again it is with Cobalt Strike. So I propose we take a look. I have the capture here. Now what I'm going to show you here, so this is Cobalt Strike beacon that uses HTTP, but of course the traffic of Cobalt Strike is encrypted. And we don't have the key to decrypt it, but I'm going to show you how you can still try to make some sense and figure out if any commands were executed or not. So here we have the capture file. Let's see if we can find the stager that downloads the beacon. So I filter for HTTP. And what I'm going to filter now is requests URI here, a regular expression. I'm going to try to match a part that starts with four alphanumerical characters. So this is the part of the stager that downloads the beacon. And this is part of four alphanumerical characters. And there's also a property that if you take the sum, the check sum eight of these characters, that you end up with a particular number. I made videos and blog posts about this set zero to nine. And we want this four times. And I'm already going to press enter here and I have several here. And I'm going to say this also needs to be only this. So start with that and then end like this. Okay. And here we have one. So this is the IP address here of the C2 server. So let's already filter on that one. So what I often do here is say apply as filter selected. But now this is here for destination. But I want this also for source. So I'm replacing this with ADDR. And then I have packets going to and coming from that C2. You can see the mirror. I'm going to add an extra filter. I only want to look at the HTTP like this. And now we have already a smaller list. So this here is the request of the stager. And this is the download of the shell code for the stager 29983. So yeah, that's a typical size for a stager. So let's export this file export objects HTTP. Let me sort this by size decreasing size. And here you can see from this IP address the PLO1. So let's save this one. This one save. Let's save it here and close this. Okay. And now I run my tool to analyze cobalt strike beacons. And indeed it is a cobalt strike beacon because we found the config. Okay, so this is the IP address of the C2. And there is only one. So it's not going to try out several ones. You can see it's an HTTP, reverse HTTP beacon. The part is slash CA. It will use a get method to get commands. And if it wants to post results, it will use a post method. And the part for the post method here is submit.php. So yeah, that's quite typical for cobalt strike. So let's do some filtering here now. See if we can make some sense out of this. So HTTP request method equals post. Let's see at the post commands. Sorry. I'm missing an end here like this. Okay. And there are no post commands. So this means that this beacon when it was executed there in that malware analysis environment when this beacon was running, it did not post the result back of any command. Now that doesn't mean that it didn't receive any commands because there are a couple of commands in cobalt strike that don't result in a response for the command being sent back like for example sleep command. So let's see at the get. Because get that is with what cobalt strike beacons here. The beacon here will use to get its command. And here we have our gets. Now here, if you look here, you will see this cookie. This is the metadata of the beacon like for example the host name and its internal IP address. This is encrypted with RSA so we cannot decrypt this. But this is the metadata that is being sent. Now let's see at the responses. So here we have responses. And let's filter on this. So for example, let's filter on this. Apply as a filter and select. So I'm going to add that to the existing filter like this and here I have all my responses. This response here has data. Because that one that's the initial one where the beacon is downloaded by the stager. Next one here, this one has no data. So here you can see content length zero and also there is no data. You can see here no data following the headers. So no commands here in this request. No command was transmitted to the beacon. So what I'm going to do here is I'm going to filter on that. Apply as filter. And I'm going to say and not selected. So I want to see everything that is a content length different from zero. Okay, and here we only have our answer to our request for the stager. So you can see here the PLO one. So you can conclude here that indeed that beacon has been active, the beacon has been running, but it did not receive any commands and it did not send any replies for those commands back. The only thing that it did was send out metadata with the internal IP address, the name of the machine, the name of the users and some things like that. Also, if we go back to our get here, you can see that the requests here are about 60 seconds one minute apart. And that corresponds to what we saw here in the configuration. The sleep time is 60,000. So 60,000 milliseconds or 60 seconds and the jitter. So that means the randomness of that sleep time is zero. So it will exactly be 60 seconds. So this is how you can analyze HTTP traffic for cobalt strike beacons that is encrypted. Well, at least determine if any commands were executed or not.