It’s a great year for those with IT skills with the demand booming, but hiring managers are finding themselves up against a wall when it comes to the supply side of the equation – there just isn’t enough talent to go around. Or so it seems. So while those who fit the normal IT profile are likely to be snatched up immediately, there remain plenty of job openings just waiting to be filled. And they can be, but recruiters need to start thinking differently about what an IT professional looks like.
Reconsidering Qualifications
One of the fastest ways to increase the pool of IT talent is to start shifting the emphasis away from requiring four-year college degrees. Instead, IT recruiters should start accepting qualified candidateswith IT certificates. So many IT jobs are so specific that the broad knowledge base associated with a bachelor’s degree is unnecessary.
A quality certificate program will give candidates the specific skills they need without the huge time and money investments that come with a four-year degree. From there, companies can identify employees who show potential for further training, including possibly earning a degree, but first recruiters need to open the door to new talent.
Consider Bias
Not only are IT recruiters losing out on talented candidates by focusing on degree qualifications over concrete knowledge—many companies also have walled off their efforts by functioning from a preconceived notion of the IT professional. This image is too often white and male, leaving women and people of color out of the picture.
In many cases, IT companies have built bias into their hiring procedures, largely through networking and old boys’ clubs that readily exclude women and recent immigrants, anyone who isn’t tied to the current startup culture. If a female candidate walks in to interview with a panel of white men, for example, she may immediately feel excluded from the company environment. This can impact the interview quality, as the candidate loses confidence or preemptively accepts that she won’t be hired.
Dedicate Space
Because white men have already colonized so much of the tech industry, sometimes it is not only helpful, but necessary, to dedicate specific space to those historically excluded from the industry. Twitter tried this recently by focusing on bringing women to its Flight conference. This year 29% of attendees were women, compared to only 18% last year.
This success is likely linked to the taskforce of women and minorities in the IT field that Twitter created, a group that networked with Girls Who Code and TechWomen to start shifting the participation and employment demographics in IT. More companies should consider creating teams focused on diversifying the field – Twitter has shown that even a small effort can reap great success.
Train the Next Generation
Ultimately, it may not be possible to remediate the talent shortage in IT immediately – if there aren’t enough trained professionals, even among those with certificate training, then there aren’t enough candidates for the many jobs in IT. The only solution, then, is to start training the next generation, getting them interested in IT careers from a young age. While youth today may be very skilled with navigating the tech world, they often know little about the behind-the-scenes world. That needs to change.
Microsoft is making an effort in that direction, dedicating $75 million over the next three years to build up its YouthSpark program. This program focuses on exposing students to computer science at the primary and secondary school levels with the goal of increasing the number of computer science students at the university level.
With dedicated efforts from major companies like Twitter and Microsoft, the shortage of IT professionals may finally decline in the next few years, but their success won’t just be measured by job slots filled. Until the IT field begins to reflect the diversity of our communities, the field will have a talent shortage. It’s time for recruiters to open the doors and welcome qualified candidates.
In late 2014, ESET presented an attack campaign that had been observed over a period of time targeting Russia and other Russian speaking nations, dubbed “Roaming Tiger”. The attack was found to heavily rely on RTF exploits and at the time, thought to make use of the PlugX malware family.
ESET did not attribute the attacks to a particular attack group, but noted that the objective of the campaign was espionage and general information stealing. Based on data collected from Palo Alto Networks AutoFocus threat intelligence, we discovered continued operations of activity very similar to the Roaming Tiger attack campaign that began in the August 2015 timeframe, with a concentration of attacks in late October and continuing into December.
The adversaries behind these attacks continued to target Russia and other Russian speaking nations using similar exploits and attack vectors. However, while the malware used in these new attacks uses similar infection mechanisms to PlugX, it is a completely new tool with its own specific behavior patterns and architecture. We have named this tool “BBSRAT.”
Targeting and Infrastructure
As described in earlier reports on “Roaming Tiger”, the attack observed in August 2015 used weaponized exploit documents that leave Russian language decoy document files after infecting the system. The files exploit the well-known Microsoft Office vulnerability, CVE-2012-0158, to execute malicious code in order to take control of the targeted systems.
Figure 1 Spear-phishing email delivering BBSRAT
In one case, the adversary impersonated an individual from the organization Vigstar, a Russian-based research organization in charge of the development of satellite communications and special purpose wireless devices for the Russian Federation’s defense and security agencies. The targeted email address appeared to be a Gmail account associated with Vigstar as well, and was found on a job board website for a job opening at Vigstar.
The rough translation of the body of the email is as follows:
I send you a “list of international exhibitions of military, civil and dual-purpose, conducted in 2015 on the territory of the Russian Federation and foreign states.” Waiting for your reply!
Figure 2 confirms that the decoy document that opens after the malware infects the system is indeed a list of international exhibitions that were conducted on Russian territory in 2015.
Figure 2 Decoy document that is opened after the malicious document has infected the system
In more recent months, we have identified several other potential Russian victims using AutoFocus. Analysis of the command and control (C2) infrastructure shows that the newly discovered samples of BBSRAT used the same C2 domains as previously published in the “Roaming Tiger” campaign, including transactiona[.]com and futuresgold[.]com. Interestingly, all of the previously published C2 domains have significant overlap amongst the hashes and IPs while C2s for BBSRAT contain no overlap at all. This may indicate that for the newer attack campaign using BBSRAT, the adversary may have deployed purpose-built variants and/or infrastructure for each of the intended targets.
Figure 3 Command and control infrastructure
BBSRAT Malware Analysis
Deployment Technique #1
BBSRAT is typically packaged within a portable executable file, although in a few of the observed instances, a raw DLL was discovered to contain BBSRAT. When the dropper first runs, it will generate a path in the %TEMP% directory. The generated filename is 10-16 uppercase alphabetic characters, and ends with a ‘.TMP’ file extension. The dropper will continue to write an embedded cab file in this location.
Figure 4 Header of CAB file dropped by BBSRAT
The malware will proceed to create one of the following directories depending on what version of Microsoft Windows is running on the target machine:
%ALLUSERSPROFILE%\SSONSVR
%ALLUSERSPROFILE%\Application Data\SSONSVR
Using the built-in expand.exe utility provided by Microsoft Windows, the dropper executes the following command, which will expand the CAB file and write the results to the provided directory:
This results in the following three files being written to the SSONSVR directory:
aclmain.sdb
pnipcn.dll
ssonsvr.exe
The ‘ssonsvr.exe’ file is a legitimate Citrix executable that will be used to sideload the malicious ‘pnipcn.dll’ file. The ‘aclmain.sdb’ file contains code that will eventually be loaded by the ‘pnipcn.dll’ file.
The malware finally executes ‘ssonsvr.exe’ via a call to ShellExecuteW.
Figure 5 Execution flow of dropper expanding CAB file
When ‘ssonsvr.exe’ is executed, and the pnipcn.dll file is loaded, it will begin by identifying the path to msiexec.exe, by expanding the following environment string:
%SystemRoot%\System32\msiexec.exe
It will then spawn a suspended instance of msiexec.exe in a new process. The malware proceeds to load code from the ‘aclmain.sdb’ file and performs process hollowing against this instance of msiexec.exe prior to resuming the process.
Figure 6 Sideloading execution flow
In order to ensure persistence, the following registry key is written on the victim’s machine:
In the most recently observed sample of BBSRAT found in AutoFocus, the Trojan was deployed via a downloader that used the Invoke-ReflectivePEInjection.ps1 script from the PowerSploit framework.
When the downloader executes, it will first decrypt the following two strings using a 5-byte XOR key of “\x01\x02\x03\x04\x05”:
These strings are then sequentially executed via calls to WinExec. As we can see, the second command is specifically crafted to run on 64-bit versions of Microsoft Windows. The commands in question will download an executable file and run it within the context of the powershell process.
When the above commands are executed, the downloader will initially download the ‘IR.ps1’ powershell script from the specified URL:
Figure 7 Downloader downloading the Invoke-ReflectivePEInjection PowerSploit script
This Powershell script appears to have been pulled directly from the PowerSploit framework, with no modifications made. The malware then invokes this script with a URL that points to an additional executable file. This downloaded executable contains a copy of the BBSRAT malware family.
The downloader proceeds to drop either a 32-bit or 64-bit DLL file that will execute the two previously stated Powershell commands when the DLL is loaded. This DLL is dropped to one of the following locations:
%SYSTEMROOT%\web\srvcl32.dll
%APPDATA%\web\srvcl32.dll
Additionally, the following registry keys are set depending on the system’s CPU architecture:
The COM object for {42aedc87-2188-41fd-b9a3-0c966feabec1} is specific to ‘MruPidlList’, while the COM object for {F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1} is specific to ‘Microsoft WBEM New Event Subsystem’. This ensures that the DLL specified will load when Microsoft Windows starts. It is a technique that was used by the ZeroAccess rootkit when it initially surfaced.
BBSRAT Execution
After being loaded using one of the two techniques discussed, BBSRAT malware begins execution by loading the following libraries at runtime:
ntdll.dll
kernel32.dll
user32.dll
advapi32.dll
gdi32.dll
ws2_32.dll
shell32.dll
psapi.dll
Secur32.dll
WtsApi32.dll
Netapi32.dll
Version.dll
Crypt32.dll
Wininet.dll
The following mutex is then created to ensure a single instance of BBSRAT is running at a given time:
Global\GlobalAcProtectMutex
Throughout the execution of BBSRAT, it will dynamically load functions prior to calling them, as seen in the example below demonstrating BBSRAT making a call to the WSAStartup function:
Figure 8 BBSRAT calling WSAStartup function
The malware proceeds to parse the stored embedded network configuration and spawns a series of threads responsible for network communication. This includes a series of HTTP or HTTPS requests, such as the following:
GET /bbs/1/forum.php?sid=1 HTTP/1.1 Cookie: A46A8AA9-D7D6-43FB-959DC96E Content-Length: User-Agent: Mozilla/4.0 (compatible; Windows NT 5.1) Connection: Keep-Alive Host: transactiona[.]com Cache-Control: no-cache Accept: */* Content-Type:
In the above example, the ‘1’ used both in the URI and the sid GET parameter is a global incremental counter. Every subsequent request made by BBSRAT increments this counter by one. Additionally, all variants of BBSRAT we have found use the same URL for command and control (C2) communication.
When first executed, the malware will exfiltrate data about the victim’s machine via a POST request to the ‘/bbs/[counter]/forum.php?sid=[counter]’ URL. All network data sent via POST requests uses a custom binary structure, as defined as the following:
1
2
3
4
5
6
7
8
9
10
11
structnetwork_header
{
DWORD random;
DWORD hardcoded0;
DWORD hardcoded1;
DWORD command;
DWORD length_of_compressed_data;
DWORD length_of_decompressed_data;
DWORD unknown2;
BYTEcompressed_data[];
};
The compressed_data field is compressed using the common ZLIB compression algorithm. Additionally, in the event data is being sent via HTTP rather than HTTPS, the following additional encryption algorithm is applied to the POST data:
1
2
3
4
5
6
7
8
def decrypt(data):
out=[]
forxindata:
t=(ord(x)–23)
t1=(t^62)
t2=(t1+23)&0xFF
out.append(chr(t2))
returnout
The following data structure holds the victim’s information that is uploaded by BBSRAT:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
structvictim_information
{
DWORD static_value;
DWORD major_version;
DWORD minor_version;
DWORD build_number;
DWORD platform_id;
DWORD default_locale;
DWORD unknown;
DWORD local_ip_address;
DWORD running_as_64_bit;
DWORD random;
DWORD unknown2;
DWORD struct_length;
DWORD struct_with_not_used_length;
DWORD struct_with_username_length;
DWORD struct_with_group_length;
DWORD unknown3;
DWORD struct_with_hostname_length;
WCHAR not_used[??];
WCHAR username[??];
WCHAR group[??];
WCHAR hostname[??];
};
BBSRAT accepts many possible commands that the C2 server can provide. These commands are sent as a response to the GET beacons that are continually requested via either HTTP or HTTPS. The following commands and sub-commands have been identified:
Command
Sub-command
Description
0x110010
N/A
Beacon
0x110011
N/A
Uninstall/Kill Malware
0x110020
N/A
Upload Victim Information
0x110064
0x2
Execute Command and Return Response
0x110064
0x4
Unknown
0x110064
0x5
Execute Shellcode
0x110066
0x7
Query Service Configuration
0x110066
0x9
Start Service
0x110066
0xa
Stop Service
0x110066
0xb
Delete Service
0x110066
0xc
Change Service Configuration
0x110063
0xd
Enumerate Running Processes
0x110063
0xf
Kill Process
0x110063
0x10
Get Process Information
0x110063
0x12
Free Library for Specified Process
0x110065
0x1b
Execute Command Quietly
0x110065
0x1e
Send Input to Console
0x110065
0x1f
Execute Shellcode
0x110061
0x20
List Drive Information
0x110061
0x21
List File Information For Given Directory
0x110061
0x23
Write File
0x110061
0x24
Read File
0x110061
0x25
List File Information For Given Directory
0x110061
0x27
Perform File Operation via SHFileOperation()
0x110061
0x28
Delete File
0x110061
0x29
Create Directory
0x110061
0x2a
Shell Execute
Please refer to the appendix for a full list of identified BBSRAT samples and their associated C2 servers.
Conclusion
As in many of the previous articles regarding espionage-motivated adversaries and possible nation-state campaigns, what is being observed in this attack campaign is a continued operation and evolution by the adversary even after its tactics, techniques, and procedures (TTPs) have become public knowledge. Despite the fact that the information about these attackers has been public for over a year, including a listing of many of the command and control servers, they continue to reuse much of their exposed playbook. We urge organizations to use the data from Unit 42 and other threat intelligence sources is paramount to proactively secure themselves and prevent attacks.
WildFire properly classifies BBSRAT malware samples as malicious. We have released DNS signatures to block access to the C2 domain names included in this report. AutoFocus users can explore these attacks using the BBSRAT malware family tag.
Over the past few months, I have had the opportunity to talk with a wide range of customers and prospects about their public and private cloud initiatives. Two common themes have arisen from these conversations. The first is that, while there is significant interest in leveraging the public cloud (Amazon Web Services and Azure in particular), there are many questions that still need to be answered. The second and more interesting theme was how organizational changes and an increased focus on DevOps can help improve cloud security.
Here’s why.
While participating in a cloud–focused roundtable with 30 or so CIOs/CISOs, I heard about how organizations are looking to move to the public cloud, what some of the concerns are, and how some are addressing them. The public cloud use cases I heard are primarily internal applications or those that present lower risk. One example was an internal, process-intensive forecasting tool that took days to run. In AWS, they can scale the CPU cycles up and run the application in a matter of hours – a perfect use of the public cloud. In other conversations, all internal application development is moved to the cloud, and separate resources are applied to development, testing, and production. Another way to look at it is that users are taking a cautious approach to testing the public cloud waters.
Most of the 90-minute conversation we had at the roundtable centered on risks and how to manage them. One participant was working to set up a process by which security, networking, and server teams would work together to decide which apps to move to the cloud. As part of the process, he was developing a set of criteria that would be used to decide if the associated data was cloud-worthy.
A second, significant conversation centered on documentation, and who should sign off on what is moved to the cloud. The feeling from most everyone was that most of the exec team should be aware of the efforts and associated risks – some food for thought there.
At both the roundtable and some of my customer engagements, I have been asking how users are managing the dynamics of security, networking and server/development teams. The answers vary widely. Some users admit they are managing it poorly: the groups operate in silos and security is deemed a bottleneck. To break down the walls, one user began holding social functions to bring the groups together with the premise being “get to know your co-worker.” The goal here is that, if they have some familiarity with each other, they may work more efficiently together. At least four of the other users I spoke with had taken the dramatic step of reorganizing the teams so they are working hand in hand. In addition to reorganizing, several took an additional step of offering and encouraging outside education as a means of expanding their skill set. This last step not only provides confidence in the uncertain times of reorganization but also enhances the user’s career – a win on both sides in many cases.
A final observation is that DevOps teams have become more engaged in the effort to include network security in their development efforts, and not just in their coding practices. In this case, network security is being baked into the application as it is developed through the use of tags and APIs.
These elements enable automation, a key tenant in the move towards cloud-first/cloud-ready development efforts. As new application workloads are added, tags assigned to the workloads can be used to automatically add the workload to the security policy. The result is security that keeps pace with the business.
The takeaways from these conversations were that organizations are moving to the public cloud in the right way: with an eye toward benefiting the business and an appropriate level of caution.
What are you doing to bring these teams together in your organization? Leave a comment and let me know.
