I had something similar to this happen to me on 10/30; one day prior to this FlashPlayer update attack on 10/31. In my case it was for a bogus, I believe, Adobe Reader update. Posted log details below. The update was for the DC version of Adobe Reader which I do not have installed. I have 11.0.13 installed. Of course I denied and blocked the update using my firewall. Wonder how many have been nailed and don't even realize it? [2015-10-30 16:35:31] Adobe ARM 1.824.15.7129 logging started. [2015-10-30 16:35:31] Command Line: [2015-10-30 16:35:31] could not find valid preference in product specific registry [2015-10-30 16:35:31] ProductCode: {AC76BA86-7AD7-1033-7B44-AB0000000001} [2015-10-30 16:35:31] ProductName: Adobe Reader XI (11.0.13) [2015-10-30 16:35:31] ProductVersion: 11.0.13 [2015-10-30 16:35:31] ProductUACPatching: enabled [2015-10-30 16:35:31] Using registered preference AUTO_CHECK_UPDATES [2015-10-30 16:35:47] No CRD to store [2015-10-30 16:35:49] Registered time expired [2015-10-30 16:35:52] No CRD to store [2015-10-30 16:35:52] New file object: AcroRdrDC1500720033_en_US.exe [2015-10-30 16:35:52] New file object: AcroRdrDCUpd1500920069.msp [2015-10-30 16:37:06] User exited [2015-10-30 16:37:07] ARM returns ERROR_SUCCESS [2015-10-30 16:37:07] Adobe ARM 1.824.15.7129 logging finished.
Are those logs from Adobe Updater? If yes then I don't think this is related to malware attack. I didn't hear yet about malware using Adobe's updater to spread itself. Usually fake update notification is just a script which is trying to persuade user to run executable that then infects system. But I might be wrong...
Log entries from abobearm.exe which is the updater. I did immediately check for Reader updates from its update option after the incident and no updates were available. Never saw anything like this before. Possible there was a "hiccup" by Adobe but seems a remote possibility. I did scan adobearm.exe at VT and it was clean. Makes me wonder is this vulnerability is really patched: http://h30507.www3.hp.com/t5/Securi...-become-the-bossman/ba-p/6765412#.VjlFkj8o6po -EDIT- Forgot to mention that what triggered all this activity was an alert from Eset's HIPS from an existing rule I have against explorer.exe memory modification. Adobearm.exe was indeed trying to do that. I have had that explorer.exe HIPS rule in place for some time and prior to this incident, never once received an alert about adobearm.exe trying to modify its memory. So something was clearly suspect here. I have since added adodearm.exe and adobearmhelper.exe monitoring rules to Eset's HIPS.
