FlashPlayer 27.0.0.183.exe installer trying to access Lsass.exe

[davism95037004]

During FlashPlayer 27.0.0.183 silence install we noticed the installer trying to access memory allocated by the lsass.exe process calling the "NtReadVirtualMemory" command. Have any of you noticed this behavior?, even better, can an Adobe specialist detail why the install is doing this?

Thank you.

[jeromiec83223024]

Can you provide some additional details, like the version of Windows and variant of Flash Player we're talking about (I'm assuming Active X), and the method you used to discover this?

[davism95037004]

The OS is Windows 7 Enterprise SP1 64 or 32bits

FlashPlayer AX is InstallAX.27.0.0.183.exe  deployed via SCCM

Method used: Behavioral based Antivirus

[jeromiec83223024]

Specifically, what AV product?  I just want to reproduce it with a known-pristine copy of Flash Player so that I can confirm that it's a false positive.

[davism95037004]

Sorry for the late response...We are using Carbon Black Endpoint Security.

[jeromiec83223024]

It's hard to guess about why a particular antivirus product is flagging a behavior.  If the installer you're running is authentic and unmodified, then the antivirus is throwing a false positive.  Carbon Black defines their heuristics, and is best positioned to tell you why they're flagging a legitimate installer, and what you can do about that.  I suspect that they get enough data back from the field that they should be able to determine whether or not this particular heuristic returns a high false positive rate, and what the frequent fliers are. 

I've sent this thread over to our installer engineers to see if they can provide some insight, but its a weird question (e.g. why does your high level code call some low-level system service under the hood?).  My guess is that we're either just doing things in an old-school way (we're talking about installers that were originally written for, and still work on WinXP) or those actual accesses happen underneath us as the result of calling into a system service or something.

What I *can* definitively tell you, is whether or not the binary you're attempting to deploy is identical to the one that we distributed.  If you want to give me a sha256 hash of the file, I can definitely do that.  You could also upload it to VirusTotal as a secondary confirmation...

[nolsen311]

Carbon Black (Defense, in my case) is using behavioral analysis to determine the **risk** and alerting based on that risk.

Perhaps instead of reassuring us that the installer is genuine, therefore the activity is "safe" you could do some work and give us some information about **WHY** the activeX installer **NEEDS** to read LSASS memory and what it's doing?!? This behavior _is_ high-risk, and is used extensively. 

Furthermore, your product has a long history of vulnerabilities with active exploits. Having it read protected memory doesn't give anyone "warm fuzzies", and the repeated "there's nothing to see here" doesn't help. This is not the first forum this question has been asked in, nor is it the first in which there is no answer forthcoming.

This isn't a "weird" question; it's educated professionals asking you to confirm that the behavior we see DAILY is truly EXPECTED behavior. doing things "old school" is the equivalent of saying "we just haven't bothered to learn how to do things safely or securely." Surely your "engineers" have tools at their disposal that can trace the activity of your own software.

Fix.

Your.

Software.

OTOH: the settings we're using in Carbon Black seem to kill this process every time it tries to read LSASS, and it also seems to still update properly. So... ¯\_(ツ)_/¯ I guess it really doesn't matter. We'll just keep stopping it from doing things it doesn't need to do.