In late June, multiple researchers and security entities (including researchers from ClearSky, FireEye, and U.S. Cybercom) highlighted APT33 activity in public outlets. Several of these files have already been identified and analyzed as part of ongoing discussions on Twitter regarding this activity.
This blog post examines a file identified through public resources with infrastructure links to these attacks that has not been widely examined.
As part of this activity, researchers identified the C2 domain “backupaccount[.]net” as a C2 used within a malicious HTA file hosted on attacker infrastructure. A PassiveTotal pivot at the time of this writing highlights 11 hashes associated with this domain. PassiveTotal accounts are free, but also do not offer the context behind these hash associations.
Of these 11 hashes:
– Eight are on VirusTotal.
– Two appear to be malicious documents related to this threat.
– One appears to be an AutoIt file documented in open source.
– Three appear to be malicious HTML/HTA files.
– Two appear to be malicious PowerShell scripts.
One of these scripts appears to be fairly unique, and work additional analysis:
Immediately, the connection between this hash and the C2 server is clear. The malware contains a variable on the first line, $SRVURL, containing this domain.
The malware defines the following 14 functions:
The malware enters a “while loop” (with a switch statement for “active” and “silent” mode, explained later) first calling the “Poster” function alongside a notification message for the C2. The “Encrypt” function is used to encrypt this message, and “Poster” will create a new WebClient object, using this to send a web request to the previously specified server.
After the “Poster” function, the malware calls the “Loop” function. This function serves as the primary C2 workflow for the malware. The malware will use the Receiver function (which in turn calls the Http-request function) to send a message to the C2 server (masked as a JSON). The response from this function will be parsed, with a string check to see if the beginning of the response matches the string of a command.
The following values are checked against the command string:
Each successful parsing will typically send a message to the C2 to confirm that the command has been received. A handful of commands only require short explanations. The “interactive” command expects a second numerical value to be part of the C2 response. If this value is 0, the malware sets itself to silent mode. If the value is greater than 299, it sets itself to active mode. If neither is true, it informs the operator that a valid value needs to be specified. These modes appear to modify the interval between requests, with active choosing a value between five and ten seconds and passive choosing a value between 45 minutes and 70 minutes.
The “sleep” command simply sets the mode to silent and breaks the C2 loop. The “cmd” command will inform the operator that they need to do “cmd /c” (to run the command silently), and the “exit” command will inform the user that they need to use the “close” command” to terminate the malware.
The next two commands (“Join” and “left”) can be thought of as a pair. The “join” command will call the “join” function, and it expects the parsed C2 command to contain two additional values passed to this function: a “method” and a “command.” Looking at the function, there are two valid methods: “wmi” and “reg”
The “wmi” method accepts the commands “check” and “remove.” If neither is specified, the malware will create a WMI event filter as a persistence method. If “check” is specified, the malware will use the “Privilege” function to determine if it has sufficient privileges to perform such an action (and will inform the operator if it does not). “Remove” will remove any event filter created.
The “reg” method provides an alternative persistence mechanism. The malware will check to see if there is an entry for a file named smrsservice.exe within the HKCU CurrentVersion\Run key. If the “add” command has been passed, it will create this key if it does not already exist (and inform the operator if the key has already been written). It will then download a file with this name to the users $env:APPDATA folder. The nature of this file is unknown, but it may serve as an additional payload or a mechanism for executing this PowerShell script.
The “reg” method also supports a “check” command (which reports if this registry value already exists) and a “remove” command (which removes the registry entry).
As previously mentioned, this overall “join” command is paired with the “left” command. If the C2 server specifies the “left” command, the malware will run the “remove” commands within the “join” function to perform the removal tasks described above. It will do this for both methods.
The next two commands are “download” and “upload.” Download will transfer a file from the victim to the attacker, whereas “upload” will push a file from the attacker to the victim device. The download command actually recursively traverses a directory specified by the attacker, uploading each file within this directory:
The next three commands appear to have external dependencies. “Pass” appears to expect an external PowerShell module named “invoke-pass” to be transmitted by the C2, although it is unclear what this would be/ Similarly, “ldap” expects to execute an “ldapCommand” parsed from the C2 response, and “sam” also appears to attempt to execute an additional script. As these were unavailable at the time of this analysis, this blog can only speculate from the command names that these might be intended for additional reconnaissance.
The “capture” command simply takes a screenshot, using a mechanism relatively common for malicious scripts of this nature:
Finally, if no “official” command is specified, the malware will attempt to run the C2 response as a PowerShell command via “iex” (invoke-expression). It will send the results of this command to the C2 server via the same Poster function.
At this point, the command loop will continue.