How to read an encrypted quarantine file?

Elastic Security Endpoint Security
1

Hello, there's a malware on an endpoint I manage, Elastic Defend put that malware in C:\.equarantine\xxxxxxxxxxxxxxxxxxxxxxx something like that.

I went there and grabbed the file for analysis in my sandbox. It is an encrypted file, I want to decrypt it so I can analyse the malware in my sandbox.

I found the following: Configure an integration policy for Elastic Defend | Elastic Security Solution [8.13] | Elastic

There, it says this:

When Prevent is enabled for malware protection, Elastic Defend will quarantine any malicious file it finds. Specifically Elastic Defend will remove the file from its current location, encrypt it with the encryption key ELASTIC, move it to a different folder, and rename it as a GUID string, such as 318e70c2-af9b-4c3a-939d-11410b9a112c.

So we know the encryption key is ELASTIC. Now, how to decrypt? What's the cypher?

And before anyone suggests it: No, I will not add an endpoint exception to "restore" the malware on the endpoint.

I want to grab the malware from quarantine and analyse it in my sandbox, Elastic documentation even tells us how to do that:

You can access a quarantined file by using the get-file response action command in the response console. To do this, copy the path from the alert’s Quarantined file path field (file.Ext.quarantine_path ), which appears under Highlighted fields in the alert details flyout. Then paste the value into the --path parameter. This action doesn’t restore the file to its original location, so you will need to do this manually.

Cool! But file is encrypted with encryption key ELASTIC, what's the cypher, how to decrypt?

2

Hi @lamp123432

I opened a documentation update request for that page to clarify the encryption scheme and how get-file works.

The ELASTIC encryption for the quarantined file is a rolling XOR. The file is XOR'd with the repeating pattern ELASTIC to prevent it from being runnable, not to prevent your ability to do exactly what you're trying to do.

get-file automatically undoes that XOR, so if you use the get-file response action after you unzip the retrieved file there will be no XOR to undo. You can verify that by hashing the retrieved file and comparing that hash to the hash in your original alert.

I hope that all helps and makes sense.

2 Likes