search

Apr4h / CobaltStrikeScan

Scan files or process memory for CobaltStrike beacons and parse their configuration
MIT License
893 stars 114 forks source link

ArgumentException in Beacon.cs #3

Closed x3419 closed 3 years ago

x3419 commented 3 years ago

Hi, I hope its okay that I raised another issue. I tested this with CobaltStrike beacon v4 on x64 injected threads on two different Windows 10 VMs and it produced the following output:

Scanning processes for injected threads Found injected thread Process : \ Process ID : 4592 Thread ID : 5484

Scanning injected thread for CobaltStrike beacon

Unhandled Exception: System.ArgumentException: An item with the same key has already been added. at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource) at System.Collections.Generic.Dictionary2.Insert(TKey key, TValue value, Boolean add) at CobaltStrikeConfigParser.Beacon.ParseTLV(Byte[] configBytes) at ConsoleUI.Program.GetBeaconFromYaraScan(Dictionary2 beaconMatchOffsets, Byte[] bytes) in C:\Users\\CobaltStrikeScan\ConsoleUI\Program.cs:line 167 at ConsoleUI.Program.Main(String[] args) in C:\Users\\CobaltStrikeScan\ConsoleUI\Program.cs:line 52

I'm unable to debug CobaltStrikeConfigParser in the solution because of the build order so I wasn't able to dig deeper. I tried adding some try catch blocks and checks for whether the dict contains the key, but that doesn't seem to help.

Thank you!

Apr4h commented 3 years ago

No worries, thanks for raising. I'll do some testing /debugging but it would be helpful if you could provide me with a procdump (all process memory) of the process with the beacon that is causing the exception. I suspect that this could be because I had to rely on some 3rd-party reporting of v4 beacon configuration (didn't have a sample) which wasn't completely accurate...

If you wish to debug yourself, it might be easiest to use commit: 467751faf8b6ced2cf62eae5558252380c3f6449 as this is before Costura.Fody was added to the project, so you should be able to build the entire solution and set breakpoints effectively.

x3419 commented 3 years ago

I've uploaded the memdump here: https://easyupload.io/y22cxl Thanks I'll try that commit. If you need a v4 beacon sample just let me know.

Apr4h commented 3 years ago

Thanks! With your memdump I was able to work out that while very similar, config fields do differ slightly between versions 3 and 4 of Beacon. I've added some fixes so that the parser will continue/skip when it reaches a v4 field that it doesn't know how to parse correctly. In this case, the output may not be a complete extraction of the Beacon's configuration but hopefully still contains a lot of useful data. Here's what CobaltStrikeScan managed to retrieve from the memdump you provided:

image

Note that the proxy config fields are probably wrong, and the 'day' field was deprecated with Beacon v3.4 so this is also obviously not accurate here. I probably don't have time to dive deeper into the v4 config in the short term but if you'd like to improve the v4 config parsing I'd be more than happy!

These fixes have been added to the most recent commit: 6730a4d61d0d686a0e1e4736768f3210995d4803 - I'll also include a new release.

Apr4h commented 3 years ago

As a side-note, you should also be able to set and hit breakpoints anywhere in the code without reverting to a previous commit (I worked on this issue without reverting). Just make sure that if you're modifying the code from one of the libraries, the matching compiled .dll file is also updated in the "Costura64" folder of the ConsoleUI project - as this is where the code will be executed from.

x3419 commented 3 years ago

Awesome! That fixed the issue. I appreciate the help