Fun with Creating a VBS Payload to Bypass Endpoint Security
A Quick Analysis of a Valak Malware Variant
Introduction: Creating Yet Another Fun Payload to Bypass Something
Rather than focusing on a novel LOLBAS payload that triggers from a system and bypasses an endpoint security solution, I’ll show you an alternative method that can provide a deeper understanding of how your controls layer together: Why do you think it is so important to do a “Purple Teaming” phishing payload simulation that is truly end-to-end and realistic? It doesn’t just show bypass of a single detection or prevention technology or process. By end-to-end, I mean let us simulate an end-user payload that not only bypasses email controls such as SMTP content security scanning, but also the endpoint security solutions such as EDR, EPP, and traditional Anti-Virus. Let us work hand in hand with the SOC or MSSP to see if the human analysts can detect this in the logs in true Purple Team partnership, and let’s ensure that the logs are correctly configured and enriched to provide this visibility. Let us work with the enterprise defenders to help improve their processes and technology for a simulated payload that is real. In this post, I’ll walk through how to create a little fun with a VBS Payload delivered through a VBA Macro enabled Excel document. It will show you a very simple example of this.
While I was writing this post, a little security incident triggered that was so relevant to this discussion, I had to add it in. After the phishing simulation, I’ve added a quick analysis of a Valak malware variant that hit one of our customers and relates to a new and stealthy little VBA Macro.
Why Does This Matter?
This matters because it is what a lot of enterprises face on a daily basis. I was talking to a CISO and our MDR team about being able to show a payload that could bypass one MDR vendor while another one would be blocked. But I received some push back. This wasn’t realistic enough because it needed to tell the entire customer story. It is true. The customer can always say, well our Proofpoint or Mimecast will prevent the email from hitting our user’s inbox. How does the malware payload deliver and stage at all layers, including inbound email flow and endpoint execution?
Purple Teaming Phishing Payload Simulation
Let us create a payload and some test case scenarios where we can test sending an email with a payload that arrives in the target inbox pristine. First, It helps to have a GSuite attacker/victim as well as an Office365 attacker/victim in your lab to test these phishing scenarios within and between clouds.
- Stand up a new Gsuite attacker domain. Send phishing payload against an Office365 hosted customer.
- Stand up a new Office365 attacker domain. Send phishing payload against an Office365 hosted customer.
- Verify if the payload is blocked with default settings turned on.
- Verify if the payload is blocked with Office ATP service.
I’ve set up some test accounts with Office 365 and GSuite because I want to verify how an attacker could white list through a trusted CSP to send from one “Cloud” to another and what the impact is. In this test, I observed that GSuite blocked the outbound Macro VBA when the attacker sent to an Office365 hosted victim. But Office 365 allowed it through with default settings between two different customers. It turns out that you need to not only have purchased and enabled the Office ATP subscription but it also needs to be correctly configured with the correct policy that detects and quarantines malicious VBS Macros.
VBS Payload Demo: Creating a Manual Payload
Let’s walk through the VBS Payload delivery system. Microsoft Excel and Word VBS Macros are a lost art and still very effective for carrying malicious payloads. They are still observed in the wild on a frequent basis, as research shows. Why is this? It just so turns out that Office applications are still very popular and so is macro functionality for advanced calculations and complex workflows. VBA applications embedded into Microsoft Excel documents are especially useful to some companies.
This test case was heavily influenced by reading Wil Allsopp’s “Advanced Penetration Testing: Hacking the World’s Most Secure Networks.”
You can use some default templates in Excel for creating budgets, which is exactly what I did for this testing.
What we are doing above is avoiding the usage of AutoOpen() function, which tends to get flagged more by AV engines. We are relying on a pretext of getting the target to click on the “Calculate” Macro button, which will launch the desired VBS function.
Now change the variables as desired to match your simulated attack infrastructure. The VBS code is located at this gist here.
Now at this point, we have our attack infrastructure setup. Let’s craft the pretext and send it to our victim. In our testing, this Macro-enabled Excel spreadsheet was sent between two Office365 customer domains with all default settings and no detections or warnings. This email was received in our victim’s inbox.
Let’s just assume that the pretext was believable and the user downloaded and opened the Excel spreadsheet, following all prompts in the pretext.
Finally, you should see that the reverse shell payload was caught by the shell catcher listener in the cloud using ncat with an encrypted TLS session! You should see a Windows CMD prompt at this point.
Summary
- We created a VBA function that relied on the user to click on a Macro enabled button.
- We didn’t rely on the AutoOpen() function, which makes this testing a little more stealthy.
- The VBA function, when clicked, writes a VBScript in the user profile directory.
- The script is executed within VBA.
- The script downloads an executable (ncat.exe) from an Nginx web server.
- The script runs ncat.exe to shovel a shell to the cloud-based C2 server, using a TLS transport.
- We’ve used an innocent-looking VBA macro that carries a VBS payload, writes it to a file, and executes it! This is a dual-stage VBS that simulates what a more involved C2 framework would utilize.
This technique has been verified to bypass at least one EDR vendor. So have fun with it but please only use it for good, in better understanding and defending your network. Note that this is a very basic example. The next steps would be obfuscating the VBS and using compression/encryption with the delivery system files. With this Purple Teaming Phishing test case, we were able to bypass any email detections as well as bypass an endpoint EDR solution. This is a lot more valuable than just testing one single prevention or detection layer as it simulates an attack end-to-end.
Enter the Valak
While I have been working on this article, one of our Security Analysts helped triage a report from a customer on a suspicious word document. It ended up being a Valak Malware variant a little distinct from some of the prior writeups describing how it works. It was a password-protected Word 97–2003 documented carrying a VBA/VBS payload. Below are some quick and dirty notes on an initial analysis of this. Unfortunately, the staging server (where it looks like the 1st stage was trying to drop some more malware from) was shut down before we had a chance to collect more information.
- Friday, July 31st, 2020: User reported suspicious word document.
- Friday, July 31st, 2020: Security Analyst performed triage with the upload of word document to Hybrid Analysis.
- Inquest API link here:
- Tuesday, August 4th, 2020: Started working on sandbox dynamic analysis.
- An image of the email received by the user. It appears to be a reply within a previous thread from a trusted third party. This shows the tactic of an adversary compromising third parties and inserting themselves into prior email threads, where a user might let their guard down and be more inclined to “trust” opening an attachment.
- De-compressing the zip file shows a Word 97–2003 document that is password protected. Note the password contained in the email body shown above, which might be decreasing the ability of an email content scanning engine to parse that password in the email body and run it in a sandbox.
- Filename: ordain.07.20.doc
- SHA-256: bf27a7b725ef434d21f6f7aa8af4fbd2398b352eb9b1d74c46a1e4595f7ce39b
- Opening the word 97–2003 document Macro by clicking through both defaults of “Enable Editing” and “Enable Content.”
- VBA calls AutoOpen() to automatically run code after the user selects Enable Editing and Enable Content (rather than requiring a function Macro button).
- Packet tracing shows an HTTP GET request on TCP/80 to the following domain and IP address. The image is just below showing the requested PHP page and URI.
- Domain: 4xj0nhh.com
- IP: 188.127.224.179
- On the evening of Tuesday, August 4th: The web server timed out with connection refused after a period of time. This coincides with the timing of receiving the following VB error when running the VBA, when the staging server fails to serve files required for stage 2.
- On Wednesday, August 5th, we started to notice that the server is issuing RST upon any SYN TCP request on port 80. By August 5th the webserver no longer allowed a 3-way handshake.
- An image below showing the structure of Modules and Class Module files (three total) with obfuscated VBS strings.
- Runtime testing on August 5th started to show Windows Defender blocking this variant with a new signature published on August 5th:
- Microsoft Threat Intelligence change log shows an updated threat intelligence signature for this Valak variant that was issued on August 5th:
Notables
- At the time of receipt (Fri, 7/31/2020), this variant bypassed Office ATP managed subscription when prior malware was detected and automatically quarantined.
- The VBA was carried in a password protected Word 97–2003 document, with the password supplied in the body of the email.
- The sender appeared to be a trusted 3rd party and the email thread was a reply to a prior email thread between victim and sender.
- From this quick Valak case study, you can get some more ideas to make the former Purple Team test payload with VBA even more stealthy.
