Hafnium Post Exploit Detection

[pronto 6]

Servus Community,

I am investigating the post exploit activity of the Hafnium attack and have come across several DDLs that have a creation date a few hours after the installation of the backdoor (05/06.03.21).

I uploaded some of these DDLs to Virustotal and they were found to be unsuspicious. However, the temporal context makes me wonder. The creation date is (a few days) before the time when ESET detected and removed the backdoor. However, a manual scan of the files with ESET Mail Security, is also unsuspicious.

Can anyone compare these files on their system?

C:\Windows\system32>cd C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth

C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth>dir
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: ACE3-7FD2

 Verzeichnis von C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth

10.03.2021  12:12    <DIR>          .
10.03.2021  12:12    <DIR>          ..
16.08.2018  16:53             8.398 error.aspx
22.02.2019  02:28             1.856 error2.aspx
22.02.2019  04:16             7.239 expiredpassword.aspx
06.03.2021  03:37            83.328 exppw.dll
16.08.2018  16:53             6.104 logoff.aspx
06.03.2021  03:37            92.032 owaauth.dll
16.08.2018  16:53             1.106 signout.aspx
               7 Datei(en),        200.063 Bytes
               2 Verzeichnis(se), 148.422.361.088 Bytes frei

C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth>cd ..\bin

C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\Bin>dir *.dll
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: ACE3-7FD2

 Verzeichnis von C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\Bin

20.08.2019  23:03           346.848 Microsoft.AspNet.SignalR.Core.dll
20.08.2019  23:03            23.264 Microsoft.AspNet.SignalR.SystemWeb.dll
06.03.2021  03:37            83.832 Microsoft.Exchange.Clients.EventLogs.dll
06.03.2021  03:38         2.970.520 Microsoft.Exchange.Clients.Owa.dll
06.03.2021  03:37         5.029.248 Microsoft.Exchange.Clients.Owa2.Server.dll
06.03.2021  03:37           924.544 Microsoft.Exchange.Clients.Strings.dll
06.03.2021  03:37            45.952 Microsoft.Exchange.InstantMessaging.dll
06.03.2021  03:37            77.208 Microsoft.Exchange.WopiClient.dll
01.05.2018  16:36           101.032 Microsoft.Owin.dll
01.05.2018  16:36           133.288 Microsoft.Owin.Host.SystemWeb.dll
01.05.2018  16:36            53.416 Microsoft.Owin.Security.dll
01.05.2018  16:36             4.608 Owin.dll
              12 Datei(en),      9.793.760 Bytes
               0 Verzeichnis(se), 148.435.795.968 Bytes frei

C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\Bin>

Thx in advance & Bye Tom

[itman 1,659]

You can download a list of all files included in KB5000871 patch here:

Quote

Exchange server file information

Download the list of files that are included in this security update KB5000871.

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

You can then compare files you are concerned about to those listed in the spreadsheet.

Edited March 13, 2021 by itman

[schuetzdentalCB 8]

@pronto only thing i can tell you is that the file:

06.03.2021  03:37            92.032 owaauth.dll

hasn't been changed (in my environment) since initial exchange installation. but yours did. maybe you check that file and also run this scan which is quite good:

https://www.nextron-systems.com/2021/03/06/scan-for-hafnium-exploitation-evidence-with-thor-lite/

[itman 1,659]

I  will also add that attackers targeting owaauth.dll is not unique to this current Exchange vulnerability:

Quote

This technique is a new twist for APT gangs, most of which rely on phishing as an initial foothold on a network. Once legitimate access is gained via stolen credentials, attackers try to pivot internally until landing on a resource they covet—which in this case was all of the organization’s OWA credentials.

The backdoored OWAAUTH.dll, was used by OWA for authentication against the organization’s Active Directory server. The attackers also installed an ISAPI filter for IIS, which was used to filter HTTP requests to the server.

“This enabled the hackers to get all requests in cleartext after SSL/TLS decryption,” Striem-Amit said. “The malware replaced the OWAAUTH [library] by installing an IIS filter in the registry, which enabled the malware to automatically load and persist on every subsequent server restart.”

The DLL then loaded another HTTP module that grabbed the malware logic and backdoor, Cybereason said.

https://threatpost.com/targeted-attack-exposes-owa-weakness/114925/

Edited March 13, 2021 by itman

[pronto 6]

8 hours ago, itman said:

I  will also add that attackers targeting owaauth.dll is not unique to this current Exchange vulnerability:

https://threatpost.com/targeted-attack-exposes-owa-weakness/114925/

Thanks for the list of patched files and the further information. My learning curve has increased rapidly over the last few days. I could have come up with the idea of looking at the file properties in the GUI earlier. Sorry for that but having the list is more valuable.

The files have a valid signature and e.g. the owaauth.dll is also shown in the list with the exact size in bytes and version number, only the timestamp is exactly 8 hours before ours, which is probably due to the time zones.

Tommorow I compare the other files but that helps to fall asleep.

@schuetzdentalCB  Have you not patched your server? You should see a similar result.

Thx & Bye Tom

 

[Marcos 5,071]

Quote

after the installation of the backdoor

Was ESET installed on the mail server? Wasn't the malware detected?

[pronto 6]

6 hours ago, Marcos said:

Was ESET installed on the mail server? Wasn't the malware detected?

ESET Mail Security is installed on our Exchange servers and we found evidence of two backdoors. On 10.03, we ran Microsoft's detection tool with a service provider and found evidence of an infection. The service provider had already opened the directory where the backdoor was installed and we could see the file. We then scanned the system with Windows Defender and exact at that point, ESET's real-time protection jumped in and detected and removed the file. Not a good sign, the file had a timestamp of 05.03. There was a second incident on 06.03 according to ESET, though here the file was detected by ESET and removed as soon as it was created.

The first file on 05.03 was not detected as malware by ESET, that's the bad news but depending on receiving the detection pattern it could also mean that the backdoor was not used either. At least not after ESET integrated this threat into an antivirus pattern. Probably between 05.03 and 06.03 ESET has configured the antivirus pattern to the threat. If the backdoor was not used immediately, it could be that it was not used at all. In that case, we might have been lucky.

Do you know when exactly the pattern for this threat was released and what version number it had? Do you have any information on how the intruders proceeded after installing the backdoor in the wild? We are not a top target for the intruders, we think that we are a victim of the mass infection.

We have now installed ESET File Security on all servers in the domain, including those that are not connected to the Internet, and enabled Live Grid and HIPS on all of them to have as many sensors as possible that could report anomalies, and hopefully we are better protected against possible post exploit attacks. Tomorrow we will start installing Sysmon on the servers and hope to get more data about unusual activity. A little bit late but we can't be more in the dust than we are now.

Thx & Bye Tom

[itman 1,659]

14 hours ago, pronto said:

Do you know when exactly the pattern for this threat was released and what version number it had? Do you have any information on how the intruders proceeded after installing the backdoor in the wild?

Refer to this Eset blog article: https://www.welivesecurity.com/2021/03/10/exchange-servers-under-siege-10-apt-groups/ . Appears it lists everything Eset is currently detecting in regards to exploiting this vulnerability.

Good luck on finding any data on Eset signature creation date/time and the like. Eset removed that info from the VirusRadar database a while back.

[itman 1,659]

15 hours ago, pronto said:

The first file on 05.03 was not detected as malware by ESET, that's the bad news but depending on receiving the detection pattern it could also mean that the backdoor was not used either. At least not after ESET integrated this threat into an antivirus pattern. Probably between 05.03 and 06.03 ESET has configured the antivirus pattern to the threat. If the backdoor was not used immediately, it could be that it was not used at all. In that case, we might have been lucky.

You might try the Thor-Light product noted previously with link provided. It does include a YARA Win log component noted here:  https://github.com/Neo23x0/signature-base/blob/master/yara/apt_hafnium_log_sigs.yar

[pronto 6]

5 hours ago, itman said:

You might try the Thor-Light product noted previously with link provided. It does include a YARA Win log component noted here:  https://github.com/Neo23x0/signature-base/blob/master/yara/apt_hafnium_log_sigs.yar

Hm, I thought I followed the link but the site looks quite different from the ones I remember. Somewhere I took apparently a wrong turn. Thanks for bringing this up again, I'll take a closer look tomorrow.

Thx & Bye Tom

[pronto 6]

On 3/13/2021 at 5:06 PM, schuetzdentalCB said:

@pronto only thing i can tell you is that the file:

06.03.2021  03:37            92.032 owaauth.dll

hasn't been changed (in my environment) since initial exchange installation. but yours did. maybe you check that file and also run this scan which is quite good:

https://www.nextron-systems.com/2021/03/06/scan-for-hafnium-exploitation-evidence-with-thor-lite/

This is a pretty good tool, easy to use and each warning is commented with a link to an explanation. Really very good. I'm thinking about adding something like this to our general monitoring. 

Only the attacked server had anomalies, but those were the things we already knew. One issue with a compromised web.conf.bak is still open but there I remember darkly that I once created a backup of the file before I made changes to it. The file extension bak is typical for me. After that the exchange server will not have been interested in this file anymore and after a few updates the content does not match the running config. This is my personal explanation for this. All other tested servers like the other Exchange and the two domain controllers were completely unsuspicious in the analysis. According to this, we could have been really lucky.

Is there something similar that looks for potential vulnerabilities without any attempt to use them?

Thanks again for the suggestion. I don't know where I ended up when I looked at it. I found something similar but it requires having sensors or agents installed on each machine to detect the lateral movements of the intruders. That would only made sense if I already had that set it up beforehand. Therefore I discarded it.

Thx & Bye Tom

[itman 1,659]

1 hour ago, pronto said:

Is there something similar that looks for potential vulnerabilities without any attempt to use them?

Did you run the Microsoft developed PowerShell script referenced in this article: https://www.bleepingcomputer.com/news/microsoft/this-new-microsoft-tool-checks-exchange-servers-for-proxylogon-hacks/ ?

Also reference this article for latest status of this vulnerability: https://www.bleepingcomputer.com/news/security/the-microsoft-exchange-hacks-how-they-started-and-where-we-are/ . The problem is and noted in the article is APT actors were exploiting this vulnerability in early Jan.; prior to the POC even being submitted to Microsoft for remediation. Research by FireEye revealed that primarly e-mail was being pilfered during the Jan. - Feb., 2021 time frame. But the bottom line is no one at this point knows for sure what the APT's could have dropped on a targeted network.

Edited March 17, 2021 by itman

[Nightowl 202]

I wonder what Microsoft was doing all the time since January when the exploit was first reported , do they wait till all the world start exploiting and stealing data so they will start reacting ? Or is it part of the idea to let them do so ?
 

Quote

 

On December 10, 2020, DEVCORE researcher Orange Tsai discovered CVE-2021-26855, a critical server-side request forgery (SSRF) flaw that allows bypassing authentication in Microsoft Exchange.

DEVCORE named the bug ProxyLogon and, at the end of December, Tsai found a second one (CVE-2021-27065) that could be used to achieve remote code execution.

The researcher on January 5, 2021, forwarded to Microsoft a report along with an exploit chaining the two flaws to prove the validity of his findings.

 

 

Edited March 21, 2021 by Nightowl

[pronto 6]

2 hours ago, Nightowl said:

I wonder what Microsoft was doing all the time since January when the exploit was first reported , do they wait till all the world start exploiting and stealing data so they will start reacting ? Or is it part of the idea to let them do so ?

In my opinion, they tried to attach importance to their cloud products, but probably underestimated the dynamics of the situation. It seems like they have lost control in the meantime. With the implementation of Windows 10 and their Windows as a Service update strategy, one update after another is blowing up. Either they came too early or too late. The customer has not been the king anymore, rather they are being forced towards in the direction where Microsoft wants them to go.  The other global players like Apple and Google are no exception. If Google decides that any standard is no longer useful, a new standard will be introduced and the world will have to follow. You just stand by shaking your head and get the feeling that they're making fun of it, also. Sorry but I had to vent a bit...

Bye Tom

 

[itman 1,659]

Appears Microsoft is actively investigating the source of the exploit leak. As with most of these like incidents, actual source will probably be never known.

0-day exploits sell for many thousands of dollars on the Dark web. This Exchange vulnerability was probably worth $100K+ to a rogue nation state actor. As such, I believe the monetary gain temptation was to great in this incident to resist.