Replacing EnCase Enterprise

No problem i think they actually tend to be pretty specific and say encryption isnt their thing come to think of it…but one can always hope. I have used the arsenal and x-ways combo when needed with respect to windows 10 bitlocker and AES-XTS even though we also have encase. I just prefer using X-ways.

As a follow-up to "jblakley" 's and Kenobyte 's suggestion about the use of F-Response in conjunction with X-Ways & Arsenal in order to gain access to a Bitlocker-ed volume, I did a bit more searching for some related information [because that is some of what I do].

So for those that are interested, here is what was found if you are interested. I found a Blog posting at the EU company of Context on how they found a way to accomplish this need to mount a Bitlocker-ed Volume with the tools that are already mentioned.

They figured out that using Arsenal Image Mounter and also with a Hex Editor they could modify the “Number of Hidden Sectors” in the Volume Boot Record (VBR) and Windows would mount the volume. Here is that Blog posting Making an NTFS Volume Mountable by Tinkering with the VBR .

Then I found at the Security Training Share site, an article that covers the use of a Volatility Plug-in for Extracting Bitlocker's Encryption Keys. They say in this article, that this works on Windows 7 through to Windows 10, BUT this technique for 8 onward is very much a work-in-progress and it should be considered highly experimental.

If you have an interest in this technique, you may wish to visit and to check out - volatility-bitlocker Volatility plugin to extract BitLocker Full Volume Encryption Keys.

This Volatility information was written in December of last year (2017), so you may also want to see if this Plug-in has been updated and moved out of the W.I.P. state.

I hope that this information provides a bit more information to this interest and helps the visitors and members of this site who are part of this greater DFIR community.

They figured out that using Arsenal Image Mounter and also with a Hex Editor they could modify the “Number of Hidden Sectors” in the Volume Boot Record (VBR) and Windows would mount the volume. Here is that Blog posting Making an NTFS Volume Mountable by Tinkering with the VBR .
.

To be picky (as I am wink ) the issue was not with the "hidden sectors" (actually "sectors Before"), but rather with the number of sectors in the volume, "Total Sectors", seemingly there were 8 sectors (or one cluster) in excess
https://www.contextis.com/blog/making-ntfs-volume-mountable-tinkering-vbr

My colleague Matt asked the very astute question as to whether we needed to change both values, 'Number of Hidden Sectors' AND 'Total Sectors', or would just 'Total Sectors' suffice? It was a good question, and a quick check revealed that actually, we only had to change 'Total Sectors' - that was enough for Windows to mount the volume.

It is entirely possible that the issue was *somehow* caused by the process of acquisition, as they were working with E01's.
Possibly, if they had the image converted to RAW and appended a few sectors at the end, there would have been no need to change the Total Sectors in the VBR. ?

jaclaz

I personally never had to altr the VBR and my experience is on with an .e01 acquisition of a windows 10 AEX-XTS ecrypted volume. I mounted with arsenal in read only and windows recognized the drive and prompted for the recovery key. It was fairly straight forward. The elcomsoft tool would would be nice considering it supports TPM as well www.elcomsoft.com/news/699.html .

I just worked through a demo of F-Response Enterprise.

1. The Encase Remote LEF capability is not implemented, although F-Response did agree to put this on their development plan.

For those that don't know, a Remote LEF allows you to create logical evidence files on the target computer itself and that target then copies the LEF to a network file share for you. The job auto-resumes if the machine goes offline. This is has become an integral part of our enterprise data collection workflow and is working very well for us.

2. With Encase Enterprise we have pre-installed the endpoint connector (formerly servlet) on all managed computing environments which allows for rapid response and connections without having to install.

The F-Response endpoint would need to be installed as needed - it could be pre-installed, but when firing up the F-Response console, all of the deployed clients start checking in, and at over 100,000 potential endpoints, that's a lot of traffic. Furthermore the endpoints constantly try to phone home and reach a server. Therefore for it to be of practical use for us, it would require admin creds each time we wish to connect to either install the endpoint or start up a service. Not totally undesirable and perhaps a good separation of duties approach, but still those were the two issues that stopped us going forward.

If #1 is addressed, we may reconsider, and then adjust our workflow to accomodate this product.

And of course the biggest differentiator is the cost.

With regards to encryption, we do not deal with encryption 'over the wire', there is no need, just access the volume.

You can always still buy Encase – standalone, to handle encryption for you (which is a much cheaper purchase option and one we would pursue if we went with F-Response). XWF is unlikely to ever support encryption.

Note I use Encase, FEK, XWF, Intella, IEF, FTK, Netanalysis, Blacklight and Cellebrite. I am fortunate in that I can use the tool best suited for the job.

The F-Response endpoint would need to be installed as needed - it could be pre-installed, but when firing up the F-Response console, all of the deployed clients start checking in, and at over 100,000 potential endpoints, that's a lot of traffic. Furthermore the endpoints constantly try to phone home and reach a server.

I am not sure to understand (actually I am pretty sure I don't understand) the 100,000 potential endpoints reference.

Can you explain/expand?

As well the phone home sounds more like a malware than anything else. 😯

jaclaz

My workplace has over 100,000 managed endpoints. We have the Encase servlet pre-installed on all of them, makes connecting to them real easy when needed.

With F-Response, we can also pre-install, but unlike the Encase servlet that is idle and waits to be connected to, the F-Response endpoint attempts to find it's home license server every few seconds. It would be a better design decision if the f-response client sat idle and waited to be connected to. I passed on that feedback to the Shannons.

When launching the F_Response console to do an acquisition, all of those endpoints start checking in and populating the product; it's just a lot of 'busy' traffic that makes launching that console slow (almost have to leave it running).

My workplace has over 100,000 managed endpoints. We have the Encase servlet pre-installed on all of them, makes connecting to them real easy when needed.

With F-Response, we can also pre-install, but unlike the Encase servlet that is idle and waits to be connected to, the F-Response endpoint attempts to find it's home license server every few seconds. It would be a better design decision if the f-response client sat idle and waited to be connected to. I passed on that feedback to the Shannons.

When launching the F_Response console to do an acquisition, all of those endpoints start checking in and populating the product; it's just a lot of 'busy' traffic that makes launching that console slow (almost have to leave it running).

I see ) by endpoint you mean "monitored (remote) systems".

100,000 is a huge number 😯 .

If the effect of 100,000 endpoints connecting all together is only that of "slowing the console launch" you must have a heck of a network setup.

In any case the attitude to phone home and/or auto-logging sounds like a (pointless) attempt to hog needlessly the bandwidth, even if the programmers had in mind a handful or tens, maybe hundreds "endpoints" max it seems like a "wrong" choice.

jaclaz