A look at Matrix Malware

[MBYX]

A look at Matrix(RIG)​

Matrix ransomware was using a waterhole attack from a compromised website.

On detonation it appeared quiet slow and clunky to me when executed, It took time to execute which I could only figure was the level on encryption been used.

During execution note the FSKRYpfk.exe and MZl9a032.exe along with hidden CMD.exe window

There was also times where it made no attempt to hide its execution (popup command prompt windows) and could be seen working in task manager. I am guessing by that point they consider they have you owned, so no need to hide.

Later in the execution I noted additional executables launching highlighted.

Following a lot of these files lead me to the appdata temp folder

Finally after what seemed like a VERY long time in comparison to a lot of other ransomware I have executed it reached a ransom demand state. What I found unusual about this is that it was run by an executable where most ransom demands are usually dropped on the desktop or the desktop background is changed to the demand note. To a normal user this would make it harder to navigate around as the window had no way to close or minimise it.

Word documents were generated and dropped just about everywhere, an example of one here which repeats parts of the ransom demand.

The encryption appeared effective against document types, scrambling my txt, word and PDF sample documents.

It was also reasonably effective against pictures with exception of .GIF file types.

Packet capture

Starts buy quiring the gateway

Quirries a ukranian whois server - stat3.s76.r53.com.ua

r53.com.ua

registrar: ua.bestname

the victim machine then escalates to become the master browser.

SSDP (upnp) is then used to feel out the local network

Some ipv6 traffic which I currently have not worked out.

Another master browser declaration and domain enumeration

A pile of UDP traffic using what looks to be ipv6, packet inspection points mostly to

schemas.xmlsoap.org

Domain Name: XMLSOAP.ORG
Upon domain lookup I can see ICANN & MARKMONITOR are already here by this point.

end of packet capture.



I found matrix to be slow clunky and “does the job” but fortunately would be easily detected however I am not sure how successful a decryption process would be, there is talk online of using shadow explorer to browse prior shadow copies of your windows environment which matrix tries to delete, there are also references to programs designed to try recover encrypted files which I may look to trial in future “look ats” that I do.

Otherwise the packet capture and ipv6 traffic use is presenting new challenges in following the bread trail back.

Thankyou

MBYX

pdf also attached.

 

[Winter Soldier]

Interesting analysis, but please be sure to fill in all required fields, so we can look fastly at used tools, environment, etc.

The rules are in place for a good reason:
https://malwaretips.com/threads/malware-analysis-rules.61915/

 

[MBYX]

Interesting analysis, but please be sure to fill in all required fields, so we can look fastly at used tools, environment, etc.

The rules are in place for a good reason:
https://malwaretips.com/threads/malware-analysis-rules.61915/

will do sorry

 

[MBYX]

A further look at Matrix

(bluetable)​

So, I was unhappy with my packet capture from a recent look at Matrix Ransomware. There was a considerable amount of ipv6 traffic that I simply could not follow. Upon poring over this a few times I got a feel that the ransonwares activity could be seen by stepping a little further back, I was looking to closely (couldn’t see the forest for the tree’s).

Typically when I packet capture I look at the machine exploited and capture the traffic to and from it which allows for less noise but as I was not seeing what the ransomware was doing I decided to look at both the exploit machine but also the far side of my proxy and capture device to see what requests it was making on the internet.

This worked far better and I was able to get a clearer picture of what the malware was doing and surprisingly with little noise (unrelated network traffic)

Starts with a lovely dns quierry to the router for statcs.s76.r53.com.ua the Ukraine @besthosting which gets shunted along (I edited some of the captures for own reasons).



Now we see

The master browser request which we also identified but then we see a dns request for time.windows.com coming from the exploited machine. To me this appears an attempt to seize control of the master browser from an operations master server role on a network. I gather this would be part of wider plan at browser injection of sorts.

You then see a single NTP connection occur

NTP been a network time protocol used for clock synchronization (but it grabs other things) the IP belongs to a pool held by Microsoft, this resides under a public project driven to time sync, however it allows for anyone to add a server to the pool if they wish to be part of the project.

It would appear the actor is using this in part for some reporting functionality and information collection of a successful hit.


I can see the packet has

· The source

· Im looking at the fact the header checksum is disabled (not sure this is normal, be surprised if it is).

· Region and UDP data.

Obviously my VPN was set to eastern Australia at the time.

The UDP data within the frame is interesting however at this time im unsure what was transferred beyond what I observed, encryption key perhaps.



I gather from this that the actor is somehow malforming the packets to distinguish the traffic from normal time sync requests then having it report back to his server as part of the project. The server 13.65.245.138 did not respond to ping and I couldn’t see it in tracert’s so it may have been removed now.



Thankyou

MBYX

 

[MBYX]

later i thought ... hrrm what if the NTP just happened to be normally going ..
What if this was background noise that maybe i just happen to pickup and misinterpret .. aside from the fact that its typically a handshake packet where this is a single packet with no response going to the detonated machine in response to its NTP request
What must we do ... TEST AGAIN ...

 

[MBYX]

soooo some time later....

And the result of the packet capture... the NTP packet going to the exact same ip address, different day different time.

however i should note in the newer version (redtable) a lot of the traffic was quietened down .. the newer version full capture is now just this.

thankyou

MBYX