Our commitment to making prevention a core component of architecture is real. As such, we created a standard assessment methodology to help set expectations about prevention and create a prevention-based architecture strategy that builds alliances between IT and security professionals. Let’s talk about how to assess prevention readiness using that methodology.
The basis of our prevention posture assessment comes from two things:
The cybersecurity community continues to amass a significant amount of intelligence and information about attackers. We know the tools, techniques, indicators of compromise, and vectors attackers used to successfully attack organizations. However, IT and security professionals lack the ability to actively defeat many of those things we know about the attackers and techniques.
IT and security leaders tell us they’re not confident they know everything that is happening in their network.
General Sun Tzu, in 500 B.C, said the following:
“Know the enemy and know yourself; in a hundred battles, you will never be defeated. When you are ignorant of the enemy but know yourself, your chances of winning or losing are equal. If ignorant both of your enemy and of yourself, you are sure to be defeated in every battle.”
The General’s words are as true today as they were in his time. In addition, they are extremely relevant in the cyber domain. You must know the enemy and yourself to prevent successful attacks. We want to work with you in a way that allows you to know yourself so you can use what we know about the enemy to prevent successful attacks.
The figure below provides a visual about how we use the prevention-posture assessment to set expectations about prevention and create a prevention based architecture strategy with customers.
Figure 1: Prevention posture assessment
First, we separate architecture into three different areas, as shown on the left-hand side of Figure 1.
Enterprise, mobility and SaaS
Data center, cloud and SaaS
Endpoint
In this way, we ensure the “know yourself” aspect or our methodology is consistent across all architecture. The separation of architecture is a deliberate action that ensures we distribute prevention capabilities across all architecture. In addition, the separation of architecture helps make the point that we need to work directly with both the IT architects and the security architects of an organization.
Second, we align the three different architecture areas with specific stages of the attack lifecycle. As Figure 1 shows, the colors in each area of the architecture align directly with specific stages of the attack:
Aligning the areas of architecture with stages of the attack lifecycle creates a compelling discussion about the difference a modern extensible approach to prevention makes for protecting organizations. In our approach, we drive home the need to position prevention capabilities across all three areas of architecture. In this way, we can actively defend ourselves by preventing what we know about attackers. At the same time, we maintain positive control that the enterprise is operating as intended, and we know everything happening in controlled environments.
In Figure 2, we provide a list of the prevention capabilities assessed as part of the prevention posture assessment. As you read through the list, there are interesting items to note:
The capabilities are redundant across areas of the architecture and stages of the attack. This is important because we must deliver prevention capabilities from the inside out rather than the way the status-quo hardens perimeters today.
We don’t assess detect/respond capabilities, like IDS, because they are not prevention-focused. This is intentional. Frankly, we shouldn’t get “prevention readiness” credit for capabilities that don’t prevent.
The prevention capabilities are all part of the “system-of-systems” Palo Alto Networks platform approach that is fully integrated. We set the expectation for all customers that they need to field all these capabilities to get the full value of their investment.
The prevention capabilities are as relevant for IT infrastructure professionals as they are for security infrastructure professionals. For this reason, we always perform the assessment jointly with the IT and security architects.
In practice, we typically find that existing customers continue working to improve capabilities covering the Delivery and Command and Control stages of the attack. This makes sense given that the status-quo approaches emphasize hardening the perimeter. One exception for protecting against the Delivery and Command and Control stage, is that very few customers adequately protect SSL traffic. Today, it is common knowledge that threat actors take advantage of encrypted application traffic to deliver malware and control their attack. Since the amount of SSL traffic continues to grow in enterprises, customers must move deliberately to decrypt traffic and extend protection capabilities to eliminate blind areas.
In addition, we consistently see customers with immature and non-existent prevention capabilities covering the internal stages of the attack lifecycle. The limitations of extensible prevention capabilities across an architecture leaves us all at risk, and allows known attackers to move unmitigated throughout an enterprise.
Ultimately, it is your decision. A known attack methodology or technique is not advanced, and should be defeated using modern prevention capabilities. In this section, we discussed the capabilities we assess to prevent successful attacks. In the next section, we will discuss how we measure prevention capability readiness and our ability to build confidence that we know everything happening in a controlled enterprise.
Have you received your prevention posture assessment yet? If you’re an existing customer, contact your our partner or local representative to request an assessment. If you’re a potential customer, do the assessment with on of our representatives soon. The only cost is some time for your team, but it will be time well spent, as a leader.
On Thursday, November 10, 2016, TDC Security Operations Center in Denmark published a report stating they had noticed several low-volume ICMP attacks in their customers’ networks. TDC named this type of attack BlackNurse.
The security of our customers is our top priority. We have conducted an investigation into this issue and to date have found that Palo Alto Networks Next-Generation Firewall customers can only be affected in very specific, non-default scenarios that contravene best practices.
Attack details
A traditional ICMP flood attack sends ICMP requests to the target in a large volume. BlackNurse, on the other hand, is an ICMP attack that sends a low volume of ICMP Type 3 (Destination Unreachable) Code 3 (Port Unreachable) requests to the target. BlackNurse is a form of Denial-of-Service (DoS) attack and the TDC report claims that it has the potential to disrupt the target organization’s operations.
Impact
1) Palo Alto Networks Next-Generation Firewalls drop ICMP requests by default, so unless you have explicitly allowed ICMP in a security policy, your organization is not affected and no action is required.
2) If you have explicitly allowed ICMP in a security policy and have implemented our best practices for flood protection, your organization is not affected and no action is required.
3) If you have explicitly allowed ICMP in a security policy and have not implemented our best practices for flood protection, your organization’s firewalls may experience higher CPU and memory usage, which may slow down the firewall’s response. Please refer to the best practices listed below.
Recommendations
For protection against BlackNurse, we recommend that customers implement the following best practices. Specifically, please follow the below steps from the page Configure DoS Protection Against Flooding of New Sessions in the PAN-OS 7.1 Administrator’s Guide:
Configure a DoS Protection profile for flood protection. Because flood attacks can occur over multiple protocols, the recommended best practice is to activate protection for all flood types in the DoS Protection profile. However, to protect against BlackNurse, the following types of flood protection are required:
ICMP Flood
ICMPv6 Flood
Configure a DoS protection policy rule that specifies the criteria for matching the incoming traffic.
For customers using a version of PAN-OS prior to 6.1, please see the PAN-OS Administrator’s Guide for your organization’s software version listed on our Technical Documentation page and refer to the steps listed under the section ‘Threat Prevention’ > About Security Profiles > DoS Protection.
Note that firewall DoS protection is included as part of PAN-OS and does not require any software subscriptions.
Should you have any questions or need assistance with implementing these best practices, please don’t hesitate to contact our support team at support.paloaltonetworks.com.
Actors related to the Operation Lotus Blossom campaign continue their attack campaigns in the Asia Pacific region. It appears that these threat actors have begun using Palo Alto Networks upcoming Cyber Security Summit hosted on November 3, 2016 in Jakarta, Indonesia as a lure to compromise targeted individuals. The payload installed in attacks using this lure is a variant of the Emissary Trojan that we have analyzed in the past, which has direct links to threat actors associated with Operation Lotus Blossom.
As our readers and customers in Indonesia are likely recipients of this phishing e-mail, we want to release some key facts to clarify the situation.
The malicious email will have an attachment named “[FREE INVITATIONS] CyberSecurity Summit.doc” that if opened will exploit CVE-2012-0158. The legitimate invitation emails from Palo Alto Networks did not carry any attachments.
In response to this incident, we have halted our email invitations, so please disregard all new emails related to invitations to this conference, as it may be malicious.
Palo Alto Networks hosts cyber security summits all over the world, and in many cases we send invitations via email to individuals we believe would be interested in attending. Figure 1 shows a legitimate invitation email in our most recent batch of invitations that has an image for its message body.
Figure 1 Legitimate invitation email sent out regarding our Cyber Security Summit in Jakarta, Indonesia
We received a tip (thanks Marcus!) regarding a recent delivery document that we believe was attached to spear-phishing emails sent to individuals that would likely be interested in attending our conference. While we do not have detailed targeting information or access to the attack emails, we believe the malicious document was delivered as an email attachment with a filename of “[FREE INVITATIONS] CyberSecurity Summit.doc”. This file name contains the first portion of the subject of the legitimate invitation emails we sent out, suggesting the Operation Lotus Blossom actor had access to an inbox that received the invite email or received the email themselves.
The delivery document (SHA256: 61de3df463f94f8583934edb227b174c7e4473b89bd110a6f6ba44fad8c41943) attempts to exploit CVE-2012-0158 to install a payload and open a decoy document on the compromised system. The decoy is a Word document that contains an image from a previous invitation email, as seen in Figure 2.
Figure 2 Decoy document showing image of previous invitation to the Cyber Security Summit in Jakarta
Emissary Trojan that runs within Internet Explorer process. This file is 500MB in size as it has a significant amount of junk data appended to the core DLL. The SHA256 is associated with the core DLL with the junk data trimmed.
We decrypted the CVNX044.DAT file and found the following configuration for this Emissary payload:
1
2
3
4
5
6
7
Version:6.4
GUID:a1741acf–3d38–4c18–9ee9–e440f79f3bb9
C2 Server1:hxxp://103.249.31[.]49/default.aspx
C2 Server2:
C2 Server3:
Campaign Code:1019
Sleep Delay:10
This version of Emissary attempts to obtain the external IP address of the compromised system using the website “b4secure[.]com”. Figure 3 shows this HTTP GET request issued by Emissary to obtain the systems IP.
Figure 3 Emissary version 6.4 issues an HTTP GET request to b4secure[.]com to obtain an IP address for the compromised system
The Emissary payload will communicate with the C2 server from its configuration file using HTTP GET requests. These requests will an added “MSG” field that contains the configuration values in encrypted and base64 encode form, along with the a custom “Cookie” field. Figure 4 shows an example C2 beacon from Emissary version 6.4, with the MSG field and the Cookie containing the GUID from the configuration, a field “fun” that specifies which function within Emissary issued the request and the system’s IP address.
Figure 4 Emissary version 6.4 beacon to its C2 server
Insight into Threat Actor
During our analysis of the decoy document that used our Cyber Security Summit as a lure, we were able to determine how the threat actor created the decoy document. As shown in Figure 2 earlier in this blog, the decoy document was two pages that contained images that make up the legitimate invitation to the conference.
We were able to determine that the threat actor used Microsoft Word to crop these images from larger images, specifically screenshots of that the actor took of the images opened in Foxit’s PDF reader. Figure 5 and 6 show the original screenshots of the invitation that were cropped using Word’s cropping tool. These screenshots are of the threat actor’s system, which allows us to glean some intelligence on the actor.
Figure 5 Original screenshot that actor cropped to create the first image within the decoy document
Figure 6 Original screenshot that the actor cropped to create the second image within decoy document
As you can see from the screenshots above, the threat actor is running Windows localized for Chinese users, which suggests the actor’s primary language is Chinese. The “CH” icon in the Windows tray shows that the built-in Windows input method editor (IME) is currently set to Chinese. Also, the screenshot shows a popular application in China called Sogou Pinyin, which is an IME that allows a user to type Chinese characters using Pinyin. Pinyin is critical to be able to type Chinese characters using a standard Latin alphabet keyboard, further suggesting the threat actor speaks Chinese.
Another interesting observation is the clock in the bottom right corner of the screenshots, which suggest that the threat actor took these screenshots at a local time of 8:35 and 8:36 AM on October 19, 2016. The decoy document was created on October 19, 2016 at 7:51 AM, but this timestamp is in UTC not local time. Obviously the screenshots could not have been taken in the future, suggesting that the actor is at least in UTC+1 or greater. We can speculate that if the actor’s clock was set to China Standard Time (UTC+8), then it would suggest that the final decoy document was created 7 hours and 15 minutes after the screenshots were taken.
Conclusion
Threat actors associated with Operation Lotus Blossom continue to carry out attack campaigns, which in this case involved a lure associated with a conference hosted by Palo Alto Networks. We have used emails to invite individuals to this conference; however, our legitimate invitation emails contained an image within the body of the email and did not contain any attachments. We have halted our invitation emails, but recipients of previous and future related emails should scrutinize them to determine if they were sent by these threat actors.
We have published a lot of content on the threat group involved and Emissary payload used in this attack. The payload installed appears to be a relatively new version of Emissary, specifically version 6.4. The decoy document itself contained cropped images of a screenshot that allowed us to determine the threat actor speaks Chinese as their primary language.
Lastly, if you received a malicious email that has an attachment named “[FREE INVITATIONS] CyberSecurity Summit.doc”, please check the system that accessed that file for the indicators of compromise listed at the bottom of this blog. For those individuals wishing to attend the conference, please register on our official CYBERSECURITY SUMMIT – JAKARTA website.
Palo Alto Networks customers are protected from the delivery document and payload associated with this attack, as both have malicious verdicts within WildFire. AutoFocus customers can track this delivery document and payload using the Emissary tag.
Welcome back to our blog series where we reveal the solutions to LabyREnth, the Unit 42 Capture the Flag (CTF) challenge. We’ll be revealing the solutions to one challenge track per week. Next up, the Windows track challenges 1 through 6, followed by 7 through 9 next week.
It looks like we will have to unpack this ourselves before we can solve it. UPX uses the pushad instruction at the beginning to push the registers on to the stack so that it can retrieve them after unpacking and jumping to the original entry point. We can script IDA’s debugger to set a hardware read breakpoint at the location of the pushed registers on the stack to get us close to the OEP.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import idc
import idaapi
import idautils
idc.AddBpt(ScreenEA())
idc.LoadDebugger(“win32”,0)
idc.StartDebugger(“”,“”,“”)
idc.ResumeProcess()
idc.GetDebuggerEvent(WFNE_SUSP,–1);
address=idc.GetRegValue(‘ESP’)–1
idc.AddBptEx(address,1,BPT_RDWR)
idc.ResumeProcess()
After we hit our breakpoint, we can remove the breakpoint and run until the tail jump that gets us to the original entry point.
popa Instruction Followed by the Tail Jump
We can take the jump to the unpacked code and then use Scylla with our new found OEP to dump the process.
We can open our unpacked executable in Binary Ninja and can see there is a path that prints the good boy message and one that prints the bad boy message. There is a function called right before the branch that checks the key and determines what path we will take.
Main Showing the Good Boy and Bad Boy paths
If we look at the function we renamed to check_key, we can see that it moves bytes on to the stack and then checks to see if the input is 16 bytes long.
The program then enters a series of anti-debugging checks that will cause the function to return 0 (FALSE) if they are triggered. Before each check, there is also a string encoding operation performed against our string.
The first anti-debugging check is a call to CheckRemoteDebuggerPresent, which checks to see if the process is being debugged.
The second anti-debugging check is a call to FindWindowW checking for a Window named OLLYDBG, which is a popular debugger used by analysts.
The third anti-debugging check is a call to IsDebuggerPresent, which checks to see if the process is being debugged.
The fourth and final anti-debugging check uses the assembly instruction rdtsc twice as a timing check to see if the process is executing slowly and probably being debugged.
If we pass all the anti-debugging checks, we end up getting the final string operation, which checks the result of all the operations against an offset in the initial buffer of bytes. If they are not equal, the function returns 0 (FALSE). But if they are equal, the result is added, which is used as the XOR key in the final operation.
We can copy off the initial buffer and rewrite the operations in python, so that we can obtain the key.
We can open it in dnSpy to decompile and debug. We can see the key_click function looks interesting because it is tracking a state if keys are pressed in a certain order.
The keys are numbered from left to right starting at 0 for the white keys and the same for the black keys. If we press the keys in the correct order do_a_thing() is called.
This function plays a funny David Bowie video while the key scrolls in ascii art behind.
PAN{B4BY_Y3LL5_5O_LOUD!}
Windows 3 Challenge: Gotta keep your Squirtle happy
We are given an executable for the Squirtle challenge. When we run the binary we see some ascii art of Squirtle and a check for a password. If we get the password wrong, we sadly find out that we just killed a Squirtle and the program exits.
Dead Squirtle from an Incorrect Password
We can open the binary in Binary Ninja and take a look at the main function. If we look at the first branch instruction, there is a function call right before at 401070 that checks the password. We can see that it is just a string compare with the string “incorrect”.
Password Check Function
If we type the password correctly we happily find out that we didn’t kill a Squirtle and we get some more output. We have to pass some anti-debugging and anti-vm checks and then we are told that the answer is written in an answer.jpg file.
Correct Password Output
There is an answer.jpg file written after we ran the program, but it is corrupted so we need to figure out how to make the program write it correctly to disk. We can see at the end of the main function there is a loop with a multi-byte XOR key.
XOR Loop Writing the answer.jpg file
We can assume that if we pass each step we will get the correct key that will output the correct image. At each stage there is a check and then some fake rand() == rand() checks with some funny messages to obfuscate the code. Thankfully there are also helpful hints at each stage if we get stuck or are unsure of the correct path.
Sleep/GetTickCount Check along with fake rand checks
The first check is to see if there is a common debugger window class found.
The second check is to look at the Process Environment Block at offset fs: [30h+2] to see if the process is being debugged.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
BOOLfs_chk(VOID)
{
charIsDbgPresent=0;
__asm{
mov eax,fs:[30h]
mov al,[eax+2h]
mov IsDbgPresent,al
}
if(IsDbgPresent)
{
returnTRUE;
}
returnFALSE;
}
The third check uses the Windows API GetTickCount() to make sure the system hasn’t been freshly booted.
1
2
DWORD Counter=GetTickCount();
if(Counter<0xFFFFF){
The fourth check used Sleep along with GetTickCount() and wanted you to bypass the sleep call.
1
2
3
4
Sleep(1000);
DWORD Counter2=GetTickCount();
Counter2-=Counter;
if(Counter2>0xFF)
The fifth check just used the Windows API IsDebuggerPresent to find out if the process is being debugged. The sixth check similarly called the Windows API CheckRemoteDebuggerPresent to find out if the process was being debugged.
The seventh stage checked to see if there are greater than 2 CPUs.
1
2
3
4
5
6
7
8
9
10
BOOLcpu_num()
{
SYSTEM_INFO siSysInfo;
GetSystemInfo(&siSysInfo);
if(siSysInfo.dwNumberOfProcessors<2)
{
returnTRUE;
}
returnFALSE;
}
The eighth stage checked to see if there were more than 1024 GB of RAM.
1
2
3
4
5
MEMORYSTATUSEX statex;
statex.dwLength=sizeof(statex);
GlobalMemoryStatusEx(&statex);
if((statex.ullTotalPhys/1024)<1048576)
The final check looked to see if the CPU hypervisor bit was set.
1
2
3
4
5
6
7
8
9
10
11
12
BOOLhv_bit(VOID)
{
intCPUInfo[4]={–1};
__cpuid(CPUInfo,1);
if((CPUInfo[2]>>31)&1)
{
returnTRUE;
}
returnFALSE;
}
We can step through the program in a binary and make sure the correct path is taken. Then we will get the correct image.
Graph Trace of the Correct Path
We could also get the correct key at each stage and grab the buffer of the XOR’d image and decrypt it with python.
We can finally decode the binary and obtain the key (Sorry :)).
PAN{Th3_$quirtL3_$qu@d_w@z_bLuffiNg}
Windows 4 Challenge: 99 bottles of beer on the wall, 99 bottles of beer. Take one down and pass it around, 98 bottles of beer on the wall. Nah, you need to just pass the jugs of beer around.
For this particular challenge, participants were given an x64 binary asking for a valid serial number.
If the serial number is wrong, they should see the image below.
This seems like those traditional crackmes. Let’s try to find the function that is checking users’ input. In order to find it, we should always look for suspicious strings if applicable.
Using Hopper, we found the following strings as indicated in the image below.
So let’s pick one of the “strings” and see where it was referenced.
Ok, let’s try and see whether we can find any GetDlgItemText/GetDlgItemTextW API calls. Ok, it seems like we got one at 140001464.
If we step debug it and follow the flow, we will come across a string length check at 1400014b3. Now we know that the input string must be 32 characters in length.
Stepping through again, at 140001500 we will encounter a check to ensure that the input characters must be 1, 2 or 3. This makes sure that the serial for this challenge is only comprised of 1, 2 and 3.
If we were to analyze the application at 140001750, we can see that there is an array with an initial capacity of [0, 13, 7]. However the maximum capacity of the “jugs” is [19, 13, 7] and the expected end state is having the array be [10, 10, 0]. You basically have three “jugs” with a size of 7, 13 and 19. The 7 and 13 size “jugs” are filled and the container with size 19 is empty. What you need is 10 in two of the containers (13 and 19).
Let’s re-write it in pseudo codes. Let’s assume that 3 “jugs” are under the array, M and the 3 jugs are a,b and c.
At first it may seem to be very confusing what is actually going on here. But let’s take a closer look.
This is the limit of the jugs.
1
2
3
4
5
6
7
8
9
10
Limit:19137
———————————–
ABC
Jug:1|2|3
Water:0|13|7
If[B]+[A]>Limit–of–[A]
Fill[B]andput the remaining in[A]
Else
Fill[B]andclear[A]
Now in the serial, if we were to start with 31, it simply means to fill up jug C to jug A.
So the aim of this is to move around the “beer” so jug A == 10 and jug B == 10.
We would have realized that this is the classic “Liquid Pouring Puzzle” that some, if not most of us, have seen while we were in school.
You can write your tool based on the findings. But if we were to do it with pen and paper. We should get something like the one below.
Upon running RGB.exe, we’re presented with three sliders, presumably corresponding to the RBG colors, and once you’ve set their values you can check them. This indicates that we’ll need to figure out the correct three values to access the key.
Wrong values
A quick look at the PE file with Exeinfo shows that it’s a .NET program, which can be unpacked with de4dot.
Checking binary type
Running de4dot against the executable creates a new file, “RGB-cleaned.exe” that we can then decompile with dnSpy to look at the underlying source code.
Deobfuscating binary
When looking at the source code, we come to the challenge that we’ll need to solve.
Algorithm
Simply put, three conditions need to be met to get the MessageBox we want to display. At this point, I started poking around to see if I can just modify the code so it always prints the answer, but when you start diving into the functions being called, you can see there is a bit more going on and requires the actual numbers.
XORing numbers against array of numbers
So I decided to tackle the math aspect instead.
The three conditions that need to be met are that one equation result must equal another equation result and one of the specific values needs to be over 60. I opt to brute force it by iterating through every possible combination of numbers, knowing that each slider will be in a range of 1-255, with one being in the range of 60-255. This gives us roughly 12.5 million possibilities, 255*255*(255-60), which shouldn’t take long at all.
After a few minutes of thinking through the logic, I use the below script to find the value.
Opening up this Windows executable quickly reveals that we’re working with some shellcode. If this wasn’t apparent, the clue provided gave some hints as to what you’d be dealing with.
Discover the key in the sh>E11C0DE to rescue the Princess!
@jgrunzweig
To make things easier for challengers, I went ahead and compiled the shellcode into a working executable, versus simply giving you the raw shellcode bytes. Once opened we see that there are no imports and only seven functions.
Figure 1 Functions in shellcode and import table
Without even debugging this shellcode we can quickly scan the seven functions provided to see if anything jumps out. Sure enough, we quickly identify a function that is almost certainly RC4 at 0x40106C. The two loops iterating 256 times gives us a big hint. Working through this function, we can confirm it is in fact RC4.
Figure 2 RC4 function
We also identify a very small function which starts by loading fs:0x30, which should get a reverser’s attention fairly quickly. For those unaware, fs:0x30 points to the Process Environment Block (PEB), which holds a wealth of information. This function in question is specifically looking at the PEB’s LoaderData offset, which holds information about the loaded modules in the process. We then get the third loaded module, which is kernel32.dll, and grab this DLL’s base address (offset 0x10). This function is essentially grabbing the base address of kernel32.dll, which is most likely going to be used to load further functions.
Figure 3 Function getting kernel32 base address
We continue to identify yet another function that appears to be hashing data, as evident by the ROR13 call.
Figure 4 Possibly hashing function
At this point, let’s start stepping through our shellcode in a debugger. We quickly see multiple calls to our function that got kernel32’s base address, followed by another function that takes this base address and a DWORD as arguments. Looking through this function we see it walking through all of kernel32’s exported functions, hashing the name, and comparing it against the provided DWORD. This is a simple shellcode trick that will allow attackers to obfuscate what functions are being loaded by the malware when viewed statically. There are a few ways we can approach this. We can debug the code and rename as we encounter them. Alternatively, we can simply search for the hashes on Google. Since the ROR13 technique is so common, there are many places online that have documented these hashes, like this one.
After getting over this minor hurdle we can start to see what the code is doing to understand what it’s looking for. Looking at the code in detail, we can see that it’s building a buffer of 54 bytes and attempting to decode it against a key that is generated using RC4. In the event the key starts with ‘PAN{‘, it will display it in a messagebox dialog window.
The key is generated using a number of variables that are pulled from the machine it is running on. The first four bytes of the key are a static value of ‘b00!’. Following this, the code looks for the following data:
Current month plus 0x2D
Current day plus 0x5E
Current hour plus 0x42
The operating system major version plus 0x3C
The operating system minor version plus 0x3F
The isDebugged flag, which is pulled from the PEB, plus 0x69
The language version plus 0x5E
These values together give us a key that is eleven bytes long. With only that information, it would be very difficult to brute force. However, since we know how each byte in the key is generated, we can limit our key space for the brute force and hopefully determine what the malware is looking for.
Knowing that there are only 12 months in a year, we can assume the first generated byte is in the range between 1 and 12. Similarly, there are a maximum of 31 days in a month, giving our second byte a range of 1 to 31. We continue this pattern on the rest of the bytes in the RC4 key. Most people looked to have the most trouble limiting the key space on the operating system versions, and the language version. Fortunately, there are very few legimate operating system (OS) versions overall. The major OS version will have a value of either 5, 6, or 10. The minor OS version will have a value of 0, 1, 2, or 3.
For the language version, there is a check early on in the execution flow where the result of GetUserDefaultUILanguage has its primary language identifier verified to be 0x0, or LANG_NEUTRAL. Knowing this, we can limit the possibilities of to values of 0x0, 0x04, 0x08, 0x0c, 0x10, or 0x14.
Using all of this information, we can generate a brute-forcing script such as the following.
Since then, we continued tracking this threat using Palo Alto Networks AutoFocus and discovered more details of the attacks, including target information. We’ve seen examples of this attack campaign, which we’ve named “MILE TEA” (MIcrass Logedrut Elirks TEA), appearing as early as 2011, and that it has since expanded the scope of targets. It involves multiple malware families and often tricks targets by sending purported flight e-tickets in email attachments. The identified targets include three separate Japanese trading companies, a Japanese petroleum company, a mobile phone organization based in Japan, the Beijing office of a public organization of Japan, and a government agency in Taiwan.
Attack Overview
Figure 1 shows the number of attacks considered as a part of the MILE TEA campaign since 2011. As we can see, the volume of the threats is small in total.
Figure 1 Number of threats used in the attack campaign
In the first three years, most of the reported attacks were from Taiwan. saw infections in a few other countries in Asia, but the number was miniscule. In mid-2013, the target base shifted to Japan. Since 2015, most of the reported attacks are from Japan.
Figure 2 Reports by countries
The primary infection vector is a spear phishing email with a malicious attachment. Although we collected several document based exploit files (RTF, XLS, and PDF) in this attack campaign, most of the attachments were executable files that, interestingly, suggest a custom malware installer. Attackers often use self-extracting executable files or existing installer packages to reduce development costs if they require dropping multiple files. However, in this campaign, the attacker group created its own installer program with the following features:
Windows executable with folder icon
Creates directory with pre-determined name in the same path as the installer
Copies decoy files into the created directory
Installs a batch file and malware on Temp Dir
Executes a batch script to delete the installer
Figure 3 shows examples of the custom installer and its different folder icons.
Figure 3 Custom installers with the folder icon
The use of e-flight tickets as phishing lures has been seen repeatedly for a number of years. The following is the list of malicious attachment samples that use this technique. It is the most prevalent lure used by this threat actor to entice targets for this campaign.
Table 1 Samples of malicious attachments masquerading as E-Ticket
Malware
In this MILE TEA campaign, the actor uses the following three malware families as the initial infection by the custom installer. The primary purpose of these families is to establish a bridgehead, collecting system information and downloading additional malware from a remote server.
Malware
Executable Type
Cipher
C2 address from Blog
Elirks
PE, PE64, DLL
TEA, AES
Yes
Micrass
PE
TEA
No
Logedrut
PE, MSIL
DES
Yes
Table 2 Malware characteristics
While many security vendors classify these samples as different malware families, they share functionality, code, and infrastructure, leading us to conclude that they in fact belong to the previously mentioned malware families.
Functionality – Blog Access
As described in the previous blog post, one of the unique features of Elirks is that it retrieves a command and control (C2) address from a public-facing blog service. When configured, the malware accesses a predetermined blog page, discovers a specific string, and proceeds to decode it with Base64 and decrypts it using the Tiny Encryption Algorithm (TEA) cipher. The same functionality is found in Logedrut, however, instead of using the TEA cipher, it uses DES.
A sample of Logedrut (afe57a51c5b0e37df32282c41da1fdfa416bbd9f32fa94b8229d6f2cc2216486) accesses a free blog service hosted in Japan and reads the following article posted by the threat actor.
Figure 4 Encoded C2 address posted by attacker
The routine called GetAddressByBlog() in Logedrut looks for text between two pre-defined strings. In this particular case, the malware sample will look for test between “doctor fish” and “sech yamatala”. The threat determines encoded text is “pKuBzxxnCEeN2CWLAu8tj3r9WJKqblE+” and proceeds to handle it using the following function.
Figure 5 Code finding encoded C2 address from blog
This code deciphers the string with BASE64 and DES. So far all Logedrut samples use exactly the same key, 1q2w3e4r, for decryption. The following Python code can be used to decode the C2 address.
Elirks and Micrass employ exactly the same TEA cipher. TEA is a block cipher that operates against 64-bit (8 bytes) of data at a time to encrypt and decrypt. The author of the code added and extra cipher operation by XORing data when a block size is less than 64 bits. For example, if the encrypted data length is 248 bits (31 bytes), the code in both malware samples decrypts the first three blocks (64 x 3 = 192 bits) with TEA. The final block is only 56 bits (248 – 192 = 56), so the code uses a simple XOR operation against the remaining data. This supplement to TEA has not been widely used, and all Elirks and Micrass samples have the same static key (2D 4E 51 67 D5 52 3B 75) for the XOR operation. Due to these similarities, we can conclude that the author of both families may be the same, or has access to the same source code.
Figure 6 TEA with XOR Cipher in Elirks and Micrass
Infrastructure – C2 Servers
Based on our analysis, we see that only a handful samples share the same infrastructure directly. The threat actors carefully minimize reusing C2 domains and IP addresses among their malware samples, and yet they prefer using servers located in Hong Kong no matter where the target resides.
Figure 7 Location of C2 servers
Target Analysis
Identifying targets from spear-phishing emails
We found a spear phishing email sent to a government agency in Taiwan on March 2015. The email sender masquerades as an airline company, and the RAR archive attachment contains the custom installer named Ticket.exe that drops Ticket.doc and Micrass malware.
Figure 8 Spear-phishing email sent to an agency in Taiwan
During the analysis of the email, we came across an article in a Taiwan newspaper from February 2014 that alerted the public about a similar email message being widely distributed that contained a malicious attachment. The only difference between the email messages in Figure 8 and in the news article was the date. The adversary reused the email message more than a year ago.
Identifying targets from decoy files
The most interesting part of this attack campaign is that the threat actor has been using stolen documents from previously compromised organizations to perform additional attacks since early 2015. These documents are not publicly available nor do they look to be created from scratch by the attacker. Because they contain sensitive data tying to the specific business, it is unlikely that a third party would be able to craft them.
The following figure shows the decoy file installed by a sample identified in early April 2015. The file is a weekly report created at the end of March 2015 by a salesperson at a Japanese trading company. The report includes various sensitive information specific to their business.
Figure 9 Weekly report from a Japanese trading company
The properties identified within the document indicate that the company name matches the context, and the person who last modified it is the same individual seen in the document itself. Because of this, the file appears legitimate and it’s very unlikely that this document would ever be made publicly available. The threat actor almost certainly stole this document soon after it was created, and reused it as the decoy for next target within a week of the theft.
Figure 10 Property of the decoy document
Another installer found in Japan in May 2015 also contained sensitive information. The decoy looks to be a draft version of a legitimate contract addendum between the subsidiary of a Japanese petroleum company based in Australia, and a China-based company. The document provides details of the deal, including price. It contains a bunch of tracked changes by what appears to be two Japanese speaking individuals. We have confirmed that one of the individuals was a manager of an overseas project of the parent company in Japan by the official release of personnel change in 2013. The file is also considered to be stolen from a target organization and used for decoy for the next attack.
Figure 11 Contract addendum decoy file
In addition to those examples, we found the following decoy files that are likely stolen from previously compromised organizations.
Organization
Type of document
Beijing Office of a public organization of Japan
Budget Report
Another Trading Company in Japan
Internal investigation document
Mobile phone organization in Japan
Inventory of new smartphones
Table 3 Potential source of another decoy file
We cannot confirm whether those files were stolen as part of the MILE TEA campaign or not. Either way, it’s difficult to imagine that the threat actor sent those internal documents to entirely different organization or industries. One plausible explanation would be that the threat actors target different persons or departments within same organization or industry.
Identifying target from Malware
So far, we have described two trading companies in Japan that are possibly targeted. In addition to these two companies, there is another company in Japan that could be involved in the attack campaign as well. A sample of Logedrut was identified and is capable of communicating with C2 through an internal proxy server in the compromised organization. The sample contains an internal proxy address for a trading company in Japan as seen in String7 in the image below. Thus, the sample is specially crafted for this specific enterprise.
Figure 12 Internal proxy address in Logedrut
Conclusion
MILE TEA is five-year-long targeted attack campaign focused on businesses and government agencies in Asia Pacific and Japan. The threat actor behind this maintains and uses multiple malware families, including a custom installer. The actor is interested in organizations that conduct business in multiple countries. The trading companies cover an immensely broad area, from commodity products to aviation around the world. Another possible target is a Japanese petroleum company that has multiple offices and subsidiary companies in overseas countries. A public organization in Japan and a government agency in Taiwan were also targeted.
Palo Alto Networks customers are protected from this threat in the following ways:
WildFire accurately identifies all malware samples related to this operation as malicious.
Domains used by this operation have been flagged as malicious in Threat Prevention.
AutoFocus users can view malware related to this attack using the “Micrass”, “Elirks“, and “Logedrut” tags.
Indicators of Compromise
Note: We omitted some hashes containing potentially stolen documents from the compromised organization.
