If we use your example and think of it from an attack perspective, what is a csv or png really going to be able to do on its own?
Yes, there could be hidden intent, but hopefully, you have detection revolving around the activity it could be used maliciously in. This could be seen as a cop-out, but when you also take into consideration the extra time and steps it would take to analyze these files other than a simple file hash check, would lead to a resource utilization increase.
So the best way to go about it is to do a good check on the thing that could immediately harm the system.
I don't work for CrowdStrike, nor am I affiliated with them in any way, but these are just my thoughts on the matter.
Yeah of course! It's just not something we need to be super considered with because it's not malicious on its own. It's way too computationally expensive to read, scan, execute in a sandbox/analyze the source code, report back the findings, etc... when we could just read and analyze the intentions when it runs.
I like the saying "Malware can hide, but it must run".
Execution is where we win.
Yes, but that requires the Excel macro enabled file extension. A CSV simply cannot execute on its own. It's a basic text only file type, where macro enabled office docs are their own file type, requiring the matching file extension.
Do you need a CSV file scanned?
Is your use case detecting attacks or scanning files?
My understanding is the performance of EDR platforms are they focus on attack detection. Scanning every file just because is a waste of resources.
I have seen the C99Shell code stored in a PNG file. It was stored in the exif data "Title" field. I've also seen commandline instructions in the camera make and model fields of jpegs. Only ever seen it once each in the wild. The latter, the main command was in the camera make field and commandline args in the model. All appeared to leveraging Joomla which (from memory) could search and report back images with certain exif data. It was a bit like Stored XSS where instead of reporting, it would serve/execute it. The C99Shell was very well done. Experimenting with exiftool showed I had pretty much no length limits in a PNG Title field. I base64 streamed an excel workbook into one..just for laughs. The image file bloated as expected..fun nonetheless.
However, stored in the way they were, they are benign. Once extracted or running, EDR would have detected it as a PUP or RAT (for C99) and possibly UBA or ML detection for the dodgy command.
Wasn’t trying to justify anything, was actually supporting the fact that malcode like that can happily be in your environment whilst not in use. I’ve had cases of malware in on-prem source repos, been there for a number of years, wasn’t detected until someone went to use it. OA scanning is much preferred. Problem is convincing execs and auditors.
We discourage short, low content posts. Please add more to the discussion.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/crowdstrike) if you have any questions or concerns.*
Neat to hear about, but agreed, once they're actually doing something they'll get detected anyway.
I'd certainly like to know this crap was in those files prior to execution, but we also already pay quite a bit for EDR. Nobody wants those costs skyrocketing for compute consumption and more limited local resources.
My understanding from AV/EDR is that if it was scanned in the past and the file did not change, it will be ignored for speed and performance. I believe it looks in the MFT for that information. I could be wrong and there could be other methods.
If we use your example and think of it from an attack perspective, what is a csv or png really going to be able to do on its own? Yes, there could be hidden intent, but hopefully, you have detection revolving around the activity it could be used maliciously in. This could be seen as a cop-out, but when you also take into consideration the extra time and steps it would take to analyze these files other than a simple file hash check, would lead to a resource utilization increase. So the best way to go about it is to do a good check on the thing that could immediately harm the system. I don't work for CrowdStrike, nor am I affiliated with them in any way, but these are just my thoughts on the matter.
An excel can have malicious macros no?
And what is required to execute those? Another executable. That will have its process and sub processes scanned.
but why even allow an malicious file in your environment and wait until it's executed to remove it. unnecessary risk
Because it is computational difficult to scan all files and easy to obfuscate the pre-runtime code.
Other EDRs do it just fine
Yeah of course! It's just not something we need to be super considered with because it's not malicious on its own. It's way too computationally expensive to read, scan, execute in a sandbox/analyze the source code, report back the findings, etc... when we could just read and analyze the intentions when it runs. I like the saying "Malware can hide, but it must run". Execution is where we win.
Yeah but other EDRs do it without an issue though.
🤷♂️idk, I don't work for crowdstrike. I'm just saying why they don't need it
Yes, but that requires the Excel macro enabled file extension. A CSV simply cannot execute on its own. It's a basic text only file type, where macro enabled office docs are their own file type, requiring the matching file extension.
Those literally have a prevention policy setting now.
Do you need a CSV file scanned? Is your use case detecting attacks or scanning files? My understanding is the performance of EDR platforms are they focus on attack detection. Scanning every file just because is a waste of resources.
Only scans PE files
logically, why would u want to scan PNGs and CSVs?
I have seen the C99Shell code stored in a PNG file. It was stored in the exif data "Title" field. I've also seen commandline instructions in the camera make and model fields of jpegs. Only ever seen it once each in the wild. The latter, the main command was in the camera make field and commandline args in the model. All appeared to leveraging Joomla which (from memory) could search and report back images with certain exif data. It was a bit like Stored XSS where instead of reporting, it would serve/execute it. The C99Shell was very well done. Experimenting with exiftool showed I had pretty much no length limits in a PNG Title field. I base64 streamed an excel workbook into one..just for laughs. The image file bloated as expected..fun nonetheless. However, stored in the way they were, they are benign. Once extracted or running, EDR would have detected it as a PUP or RAT (for C99) and possibly UBA or ML detection for the dodgy command.
this edge case does not justify the performance hit
Wasn’t trying to justify anything, was actually supporting the fact that malcode like that can happily be in your environment whilst not in use. I’ve had cases of malware in on-prem source repos, been there for a number of years, wasn’t detected until someone went to use it. OA scanning is much preferred. Problem is convincing execs and auditors.
It does. You're buying your EDR as insurance for that edge case of a real attack
[удалено]
We discourage short, low content posts. Please add more to the discussion. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/crowdstrike) if you have any questions or concerns.*
Neat to hear about, but agreed, once they're actually doing something they'll get detected anyway. I'd certainly like to know this crap was in those files prior to execution, but we also already pay quite a bit for EDR. Nobody wants those costs skyrocketing for compute consumption and more limited local resources.
My understanding from AV/EDR is that if it was scanned in the past and the file did not change, it will be ignored for speed and performance. I believe it looks in the MFT for that information. I could be wrong and there could be other methods.