Malware Analysis Razy Ransomware, small insight

[ChemicalB]

This post is about Razy Ransomware posted in Hub by @erreale and here the HA reports.

https://www.hybrid-analysis.com/sam...6ccaee3023e00c26ce6433dbf3e?environmentId=100

According to this report, I found very interesting AdjustTokenPrivileges function in File Imports, ADVAPI32.dll used by malware to gain additional permissions thanks to injection.

This suggests me some considerations.

If the user has the administrator access, he can give to a malware these same privileges.
So it is recommended not to perform the access as administrator because if you run a malware, it has the administrator privileges, and then the total control of the system.
However, if you run a malware without administrator privileges then the
malware should make an attack to gain the admin privileges.

This attack is called Privilege Escalation.

Sometimes, even if the user has administrator rights, the malware requests the privilege escalation, indeed the processes run at user-level or system -level.
User-level processes are the ones run by the user, and usually they could not manipulate the system-level processes (which are the target of malware for hide itself inside them).
But there is a technique that allows malware to attack the system-level and this technique is called SeDebugPrivilege.

This technique allows the malware to gain access to system-level processes and set the rights of an access token by enabling SeDebugPrivilege.
An access token, on a Windows system, is an object that contains security descriptors of a process, and it can be manipulated by calling the syscall AdjustTokenPrivilege.
The SeDebugPrivilege privilege is created for the purpose of debugging processes for the system-level, but malcoders have exploited this functionality to gain full access to the system processes.

If you use a disassembler you will notice that usually the access token is obtained by doing the OpenProcessToken syscall.
This function requires two parameters:
as the first parameter it is given its process handle, obtained by calling the GetCurrentProcess syscall;
the second required parameter is the access flag that in this case is passed to it the token to manipulate the privileges to query (TOKEN_ADJUST_PRIVILEGES |
TOKEN_QUERY).
Then the malware calls the LookupPrivilegeValueA syscall, necessary to retrieve the locally unique identifier (LUID).
It is a data structure that represents the specified privilege, in this case, SeDebugPrivilege.
The obtained information are used in the AdjustTokenPrivileges syscall, and a key structure PTOKEN_PRIVILEGES is also passed to the AdjustTokenPrivileges syscall.
Please note that this structure sets the bits high and bits low of the LUID by using the results obtained from LookupPrivilegeValueA in a two-step process.
The attributes section of the structure NewState are set to SE_PRIVILEGE_ENABLED to enable SeDebugPrivilege.

In this way, the malware gets the Privilege Escalation.

This is just a brief insight based on my (old) knowledge.
Please correct me if I wrote something wrong

 

[JM Safe]

Malware with privilege escalation can be defeated with Group Policy (deal with Logon and Logoff) to prevent attacks. If you want to know more look here: 3-Step Guide to Preventing Privilege Escalation

 

[In2an3_PpG]

A friend of mine has analyzed the sample and has said that he cannot find evidence of SeDebugPrivilege being explicitly targeted, but that the sample does target SeTcbPrivilege.

 

[ChemicalB]

A friend of mine has analyzed the sample and has said that he cannot find evidence of SeDebugPrivilege being explicitly targeted, but that the sample does target SeTcbPrivilege.

View attachment 204439

Thanks for your specific input, and sorry if I've caused a misunderstanding, I have not analyzed this malware, I just commented the HA report basing on my old analysis by using IDA, where SeDebugPrivilege was commonly used.
Indeed, to refer to various Privileges in the context of the Windows Api, it is provided a set of strings that identifies the Privileges:

For example:

SeCreateTokenPrivilege
SeAssignPrimaryTokenPrivilege
SeTcbPrivilege
SeLoadDriverPrivilege
SeDebugPrivilege
.... etc.

 

[Andy Ful]

Both privileges are very powerful, and pretty common in ransomware attacks. The known NotPetya ransomware used them and also SeShutdownPrivilege (to force the computer reboot and infect MBR).
With SeTcbPrivilege the process can have a fully privileged access to the machine (act as a part of the operating system).
SeDebugPrivilege is in practice equivalent to gaining the local System access.

With any of those privileges the malware can do almost anything (steal the credentials, load kernel drivers, get access to any account, overwrite critical registry keys or system files, etc.).

 

[In2an3_PpG]

Thanks for your specific input, and sorry if I've caused a misunderstanding

"Privilege escalation" is usually referred to when a vulnerability is exploited to escalate privileges but I do not see any vulnerabilities being exploited to achieve this. Windows is designed to allow elevated processes to change its token privileges. Can you point me in the right direction so I can learn from this? Even a CVE name would help a lot.

 

[ChemicalB]

"Privilege escalation" is usually referred to when a vulnerability is exploited to escalate privileges but I do not see any vulnerabilities being exploited to achieve this. Windows is designed to allow elevated processes to change its token privileges. Can you point me in the right direction so I can learn from this? Even a CVE name would help a lot.

Yes, many malware samples exploit this Windows vulnerability and I think this shoul be resolved by preventing files ability to get high privileges. An example I think could be this: CVE-2018-0952 CVE-2018-0952: Privilege Escalation Vulnerability in Windows Standard Collector Service

 

[In2an3_PpG]

Yes, many malware samples exploit this Windows vulnerability and I think this shoul be resolved by preventing files ability to get high privileges. An example I think could be this: CVE-2018-0952 CVE-2018-0952: Privilege Escalation Vulnerability in Windows Standard Collector Service

I don't understand what Windows vulnerability is being abused here though, that is what I am trying to learn more about. Do you have a CVE for the privilege escalation vulnerability this sample is exploiting? I looked up the first CVE you shared and it wasn't relevant for the sample this thread is about and the same for the second CVE you shared on the post edit.

 

[JM Safe]

I don't understand what Windows vulnerability is being abused here though, that is what I am trying to learn more about. Do you have a CVE for the privilege escalation vulnerability this sample is exploiting? I looked up the first CVE you shared and it wasn't relevant for the sample this thread is about and the same for the second CVE you shared on the post edit.

The vulnerability you are talking about is usually about winlogon.exe, which manages privileges escalation, the link mentioned by @stepseven84 is an example of an explanation about this type of Windows vulnerability. About the sample of this thread specifically the source code could exploits this Windows vulnerability in a different way but the concept is the same: the malware obtains high privileges.

 

[In2an3_PpG]

The vulnerability you are talking about is usually about winlogon.exe, which manages privileges escalation, the link mentioned by @stepseven84 is an example of an explanation about this type of Windows vulnerability. About the sample of this thread specifically the source code could exploits this Windows vulnerability in a different way but the concept is the same: the malware obtains high privileges.

I'm not referring to a vulnerability myself. I am asking about the apparent privilege escalation vulnerability. I cannot find anything about the CVE shared by stepseven84 being exploited by the sample shared in the original post, could you please send over the analysis you made on the sample demonstrating the exploitation then so I can learn from it?

BTW how does winlogon.exe "manages privilege escalation"? I didn't hear about this before and do not even understand what you are saying here but if you have any whitepapers I can read on this then it'd help me out quite abit as well.

 

[ChemicalB]

I am asking about the apparent privilege escalation vulnerability

I don't understand what CVE you want, as said before, my post is a general consideration about the HA report and, in particular, about AdjustTokenPrivileges.
Again, I have not analyzed Razy.

I do not know the specific Privilege Escalation vulnerability but it is universally known that malware/ransomware use privilege escalation to adjust their own privileges (usually they add SeDebugPrivilege)

A well known example is Teslacrypt that before running its main activity, it performs a Privilege Escalation (through
SeDebugPrivilege technique) -

Here: Threat Spotlight: TeslaCrypt - Decrypt It Yourself

- by following the pattern of the syscall:

OpenProcessToken
LookupPrivilegeValue
AdjustTokenPrivileges

The ransomware implements this technique to ensure the rights needed to manipulate files on the
the machine and all the connected drives.

Simply reading HA report I thought to add my personal considerations about AdjustTokenPrivileges and SeDebugPrivileges specifying "correct me if I'm wrong".
I am not an expert but just a self-taught and I do not think you will learn from me, I posted what I know in this context, even at the risk that my interpretations are wrong.

At this point, seeing you are quite skilled in this stuff it would be nice to see your full analysis of Razy, if you want

 

[In2an3_PpG]

A well known example is Teslacrypt that before running its main activity, it performs a Privilege Escalation (through
SeDebugPrivilege technique) -

In the research you linked to, the TeslaCrypt* ransomware sample was deployed using an exploit kit.

This ransomware is usually distributed as an email attachment or through websites that redirect the victim to the Angler Exploit Kit. In our analysis, the exploit kit delivered a malicious Flash object containing an exploit against CVE-2015-0311. The payload for this exploit was a TeslaCrypt sample.

If you are really convinced that adjusting token privileges from an administrative process is the same as exploiting a Windows vulnerability for "privilege escalation" then you can learn about submitting a vulnerability report to Microsoft here https://www.microsoft.com/en-us/msrc/faqs-report-an-issue?rtc=1

Thanks for sharing the HA report and I wish you a happy new year.

 

[ChemicalB]

In the research you linked to, the TeslaCrypt* ransomware sample was deployed using an exploit kit.



If you are really convinced that adjusting token privileges from an administrative process is the same as exploiting a Windows vulnerability for "privilege escalation" then you can learn about submitting a vulnerability report to Microsoft here https://www.microsoft.com/en-us/msrc/faqs-report-an-issue?rtc=1

Thanks for sharing the HA report and I wish you a happy new year.

Thanks for the clarification and best wishes also to you

 

[Fabian Wosar]

I don't understand what Windows vulnerability is being abused here though, that is what I am trying to learn more about.

There is no CVE, because it's not a vulnerability. Windows has no concept of "administrator", unlike Linux with the user with the UID 0 (root), who is just allowed everything. Microsoft considers everyone an "administrator" that has or can enable any of the following rights:

• SeTcbPrivilege
• SeBackupPrivilege
• SeCreateTokenPrivilege
• SeDebugPrivilege
• SeEnableDelegationPrivilege
• SeAuditPrivilege
• SeImpersonatePrivilege
• SeLoadDriverPrivilege
• SeSecurityPrivilege
• SeSystemEnvironmentPrivilege
• SeAssignPrimaryTokenPrivilege
• SeRestorePrivilege
• SeTakeOwnershipPrivilege

There may be more by now, but those should be the most important ones. What makes these rights so special? They are special because any of these privileges allows you to obtain all other privileges as well.

SeDebugPrivilege, for example, allows you to open ANY process on the system, ignoring any ACLs or user restrictions, and "debug" it. Which includes abilities to inject and execute code in those other processes. So you can just "debug" a process with higher privileges, inject your code in there and you run your code using those higher privileges.

SeBackupPrivilege and SeRestorePrivilege, for example, allow you to ignore any ACLs on files and read and write to them freely, ignoring any file system permissions being set up. How can you abuse it? Just replace the executable file of a program the local administrator account runs, preferably automatically during boot. Next boot, your code has all the privileges.

I think you get the idea. What that means is, that any user that can enable any of the above privileges, is considered an "administrator" (as in "is allowed to do anything and has the highest rights possible") by Microsoft. So even if malware would use SeDebugPrivilege to inject its code into a SYSTEM process, it is not considered a privilege escalation, because the user that ran that malware already had the SeDebugPrivilege right and therefore already is considered having "administrative rights".

 

[Andy Ful]

I think that In2an3_PpG was interested about vulnerabilities exploited by the ransomware to obtain SeTcbPrivilege (or other high level privilege).
But, that can depend on the infection chain. I did not make such analysis, but it is possible for a ransomware to exploit something to obtain high level privileges and then encrypt the files (one malware). It is also possible, that the infection starts from a simple script and there are two (or more) payloads - one for privilege escalation, another as ransomware, etc.

 

[Fabian Wosar]

I think that In2an3_PpG was interested about vulnerabilities exploited by the ransomware to obtain SeTcbPrivilege (or other high level privilege).

There is none though. I think people are confused by enabling/disabling a privilege and granting a privilege. These high-risk privileges are granted to each process run by an admin by default. However, they are usually granted "disabled". Check out this privilege breakdown of a process I started as an admin:

You can see that the process has all the privileges, but they are mostly disabled. Why are they disabled? Because they can be dangerous and to prevent bad things from happening, Windows makes you state your intention to use any of them explicitly by having to manually enable them first. Think of a privilege as a gun with a safety. If you have it, chances are the safety is on, so you don't shoot yourself by accident and only when you intend to use it you turn the safety off. That is what the malware does. It already has the gun, but the safety is turned on. So it turns it off.

Compare this to a process that wasn't run by an administrator:

As you can see, all the "dangerous" privileges aren't present at all and there is ideally no way to get them from that process either. So no gun for this dude and it can try to turn on or off the safety as much as it wants since there is no gun nothing happens. If it was somehow able to get a gun/privilege, that it wasn't supposed to have, that would be an actual privilege escalation. That's just not what is happening here and the malware makes no attempt to do that.

Bottom line In2an3_PpG is correct in that the malware does not escalate privileges at all. It just enables some privileges provided that its process has them to begin with.

 

[Andy Ful]

There is none though. I think people are confused by enabling/disabling a privilege and granting a privilege. These high-risk privileges are granted to each process run by an admin by default. However, they are usually granted "disabled". Check out this privilege breakdown of a process I started as an admin:

View attachment 205195

You can see that the process has all the privileges, but they are mostly disabled. Why are they disabled? Because they can be dangerous and to prevent bad things from happening, Windows makes you state your intention to use any of them explicitly by having to manually enable them first. Think of a privilege as a gun with a safety. If you have it, chances are the safety is on, so you don't shoot yourself by accident and only when you intend to use it you turn the safety off. That is what the malware does. It already has the gun, but the safety is turned on. So it turns it off.

Compare this to a process that wasn't run by an administrator:

View attachment 205197

As you can see, all the "dangerous" privileges aren't present at all and there is ideally no way to get them from that process either. So no gun for this dude and it can try to turn on or off the safety as much as it wants since there is no gun nothing happens. If it was somehow able to get a gun/privilege, that it wasn't supposed to have, that would be an actual privilege escalation. That's just not what is happening here and the malware makes no attempt to do that.

Bottom line In2an3_PpG is correct in that the malware does not escalate privileges at all. It just enables some privileges provided that its process has them to begin with.

Thanks, I know it and In2an3_PpG knows it too.
Anyway, your post was very informative (as always).
Still, there is no analysis available online, which could show for sure, that this malware sample did not also exploit a vulnerability to access admin rights.
If I properly understood, your post suggests that you made or saw such analysis, and indeed the Razy-ransomware has no exploit-privilege-escalation capabilities, so requires another malware/exploit to get admin rights.