sunhux
asked on
how to mitigate a legit IOC file (by virustotal) that is exploitable ?? Eg: msxsl.exe
Received a threat intel which indicated a file MSDFMAPI.INI (which has
MD5 hash value of c4103f122d27677c9db144cae1
When the above hash is entered into virustotal.com, all the security
products there rated it as non-malicious & it's from a trusted publisher.
Refer to attached for more detail: support this file is present on a user
PC (on Windows) & it's needed, what mitigations can we do?
I had one past such IOC file that was rated as safe by virustotal (think
filename is msxsl.exe ) but it's a legit file, just that it is exploitable.
So how do we deal with it (ie this IOC & the msxsl)??
MSDFMAPIntel.pdf
MD5 hash value of c4103f122d27677c9db144cae1
When the above hash is entered into virustotal.com, all the security
products there rated it as non-malicious & it's from a trusted publisher.
Refer to attached for more detail: support this file is present on a user
PC (on Windows) & it's needed, what mitigations can we do?
I had one past such IOC file that was rated as safe by virustotal (think
filename is msxsl.exe ) but it's a legit file, just that it is exploitable.
So how do we deal with it (ie this IOC & the msxsl)??
MSDFMAPIntel.pdf
do you have this file on your system? Which OS as it is not on my computer
As David says there is usually a way to whitelist it. Just be sure it is okay first.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
We certainly could whitelist MSDFMAPI.INI & msxsl.exe if we want to but
the intel come from cyber regulator so we are not at liberty to just whitelist
them (or skip adding the hashes to our AV)
Haven't tested removing MSDFMAPI.INI but if I remove msxsl.exe, there'll
be impact/disruption to Checkpoint's client that run on users' laptops.
MSDFMAPI.INI was found in at 5 users' PCs in various depts.
For msxsl.exe, I did highlight to regulator that no products in VT detects it
as malicious & VT indicates it's from a trusted publisher & advice I got was:
(1) 3e9f31b4e2cd423c015d34d630
(2) Virustotal doesn’t reflect that it is malicious because it is indeed a legitimate tool from Microsoft, much like Powershell.
(3) msxsl.exe can be used to execute malicious Javascript code to bypass protections such as application whitelisting or even can be used in phishing.
(4) Powershell as well, which it is most often used to perform fileless operations. When you do a check for Powershell at Virustotal, it would be reflected as safe too.
(5) IOCs are artefact of some incident and they can be malicious in nature, such as a real malware, or they can be tools used as an aid to execute malware
(6) Advice is that msxsl.exe is used for executing malicious stuff in this particular advisory and hence it was included as part of the IOC list distribution.
(7) I'd advise not to omit this out from your checks, as every hit on an IOC brings you towards a more accurate analysis and decision related to this advisory.
Thanks for the inputs: my personal view is if there's a 'patched' version of the msxsl, it will
fulfill both the regulator's advisory & our users' operational requirement. As for MSDFMAPI.INI,
perhaps I should make it 'read-only'?
the intel come from cyber regulator so we are not at liberty to just whitelist
them (or skip adding the hashes to our AV)
Haven't tested removing MSDFMAPI.INI but if I remove msxsl.exe, there'll
be impact/disruption to Checkpoint's client that run on users' laptops.
MSDFMAPI.INI was found in at 5 users' PCs in various depts.
For msxsl.exe, I did highlight to regulator that no products in VT detects it
as malicious & VT indicates it's from a trusted publisher & advice I got was:
(1) 3e9f31b4e2cd423c015d34d630
(2) Virustotal doesn’t reflect that it is malicious because it is indeed a legitimate tool from Microsoft, much like Powershell.
(3) msxsl.exe can be used to execute malicious Javascript code to bypass protections such as application whitelisting or even can be used in phishing.
(4) Powershell as well, which it is most often used to perform fileless operations. When you do a check for Powershell at Virustotal, it would be reflected as safe too.
(5) IOCs are artefact of some incident and they can be malicious in nature, such as a real malware, or they can be tools used as an aid to execute malware
(6) Advice is that msxsl.exe is used for executing malicious stuff in this particular advisory and hence it was included as part of the IOC list distribution.
(7) I'd advise not to omit this out from your checks, as every hit on an IOC brings you towards a more accurate analysis and decision related to this advisory.
Thanks for the inputs: my personal view is if there's a 'patched' version of the msxsl, it will
fulfill both the regulator's advisory & our users' operational requirement. As for MSDFMAPI.INI,
perhaps I should make it 'read-only'?
ASKER
>make it 'read-only'?
or set Windows ACLs on the file such that it could be accessed by certain
account only?
or set Windows ACLs on the file such that it could be accessed by certain
account only?
ASKER
There used to have a recommendation to remove PowerShell but
I guess a solution that fulfill both cyber as well as operational need
is to sort of permit PowerShell to be used by certain authorized
process/account only
I guess a solution that fulfill both cyber as well as operational need
is to sort of permit PowerShell to be used by certain authorized
process/account only
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
> You would consider the endpoint detect and response agent to level up the AV protection as a long term plan.
So in the case of msxsl.exe & the ini file, we should block IOC IP addresses from accessing these 2 files if we
need these files? Or we permit only whitelisted IP to access these 2 files. The EDR used is from Trendmicro.
So in the case of msxsl.exe & the ini file, we should block IOC IP addresses from accessing these 2 files if we
need these files? Or we permit only whitelisted IP to access these 2 files. The EDR used is from Trendmicro.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Normally there a way in every scanner to whitelist a signature + program/script path, so it no longer shows up in reports.
This allows you to remove false positives from any future scanner reports.