Joomla! has revealed it's patched twin critical flaws allowing attackers to bypass rules and create elevated privilege accounts.…
Posted: 26 Oct 2016 | 5:56 pm
Last week’s massive distributed denial-of-service (DDoS) attack on the DNS provider Dyn should serve as a wake-up call: the Internet of Things ecosystem is completely, and utterly, broken. Poorly supported and insecure devices brought an important part of the Internet’s infrastructure offline and took many high-profile sites with it.
To recap, a very large-scale attack (Dyn says that tens of millions of discrete IP addresses were part of the attack that targeted them) hit Dyn last Friday (October 21). The first attack began at 7AM Eastern time and primarily affected users on the East Coast of the United States, but was mitigated in approximately two hours. A second attack at approximately 12PM Eastern affected more users globally; mitigation took an hour. A third attack was launched later that day but was mitigated without customers being affected at all.
Where did this attack come from? A large portion of this attack was carried out by Internet of Things (IoT) devices infected by Mirai malware, which we detect as ELF_GAFGYT.DGB/ELF_BASHLITE.SM. (There is no one single Mirai botnet anymore, as its source code was released to the public at the start of October and it can now be used by any attacker.) Most of the blame for Friday’s attack was laid on the doorstep of a white label manufacturer of DVRs and webcams. This manufacturer has issued a recall for some of their vulnerable devices, which is a welcome (and potentially costly) move. It is likely that devices from other manufacturers were involved as well, however.
Figure 1. Overview of a Mirai DDoS Attack
The Attacks Will Continue Until Security Improves
It’s a bit of a stretch to call these attacks “unprecedented” – just a few weeks ago, Brian Krebs was hit with a DDoS attack by the Mirai botnet as well. What is certain is that until we find a way to secure the Internet of Things, it won’t be the last.
When it comes to the Internet of Things, the balance of power is currently in favor of the attacker: there are too many IoT devices that aren’t secured, can’t be secured, and won’t be secured. Denial of service attacks just became an even more potent threat: threatening companies with being knocked offline just became a far more potent and believable idea.
IoT itself brings real-world consequences to DDoS attacks – what happens when these devices can’t connect to their central servers? Sometimes, they don’t handle it well. It used to be that a DDoS attack was, in the grand scheme of things, only an annoyance. Now, with more and more important functions going online, it’s a serious threat.
A Broken Ecosystem
Clearly something has to be done about securing the Internet of Things. Unfortunately, saying this is a difficult problem is an understatement. We can’t expect users to suddenly become experts and secure their devices. The number one priority of end users has, and always will be: make their stuff work.
What about the sellers of IoT gear? Not all of them might have the technical know-how to fix what they sell. In some cases these sellers merely rebrand the products sold by white label manufacturers. Can a mere reseller and importer of goods actually support what they sell? The answer is: probably not.
This leaves us to the actual manufacturers of IoT gadgets. Unfortunately, commercial pressures have meant that post-sales support for these devices is poor. Security is not a priority – ease of use, new features, and a quick time to market are. An IoT OEM has no reason to invest in security – no vendor has gone out of business because their product is insecure. In addition, long-term support costs time, resources, and money – all things a manufacturer wants to reduce.
In short, no one here has the incentives to do the right thing – secure their IoT equipment. As far as security is concerned, the IoT ecosystem is broken.
Will regulators have to step in?
This breakdown in the world of IoT isn’t sustainable in the long term. Once the real-world consequences of this IoT insecurity are clear, it’ll become increasingly likely that government regulations would have to be enforced.
Regulations have long been considered unwelcome in tech circles, but would it really be that unprecedented? Most electronic devices already need to meet various safety standards. Would a certification against basic security mistakes be that far off?
It would be asking too much to ensure that any IoT gadget would have no vulnerability. However, would it be too much to ask for basic security mistakes – open ports, default credentials like admin/admin and sent without encryption – to be excised from IoT gear? If the IoT manufacturers want to make their devices part of the daily lives of their users, would it be too much to ask them not to burn down the rest of the Internet along the way?
IoT security will get better – eventually
In the long run, better IoT security is coming. The consequences of insecure IoT will become painfully clear, and it will be considered unsafe and perhaps illegal. You can’t sell unsafe cars or appliances – and in the future, neither will you be able to sell, say, an online camera with a wide open telnet server.
How will the IoT industry get better at making secure devices? In effect, they will either be forced to learn improved security practices or face not being able to sell their products at all. Simple awareness of the security risks will be enough to remove the most egregious flaws found in current IoT devices. Security vendors such as Trend Micro are also working on technologies and products that ordinary consumers can use to secure their own home networks.
We’re already seeing some signs of progress, both on the part of industry and regulators. The European Commission is now considering new regulations to cover the security of IoT devices. Industry groups have released a road map for securing IoT devices. We’re seeing the beginnings of an ecosystem start to take security seriously, and it is happening not a moment too soon.
The transition from an insecure ecosystem to a secure one will not be painless. Until we do manage to get there, we will see more serious security incidents that were made possible by insecure IoT. It is up to the IoT industry, security vendors, and regulators to help make that transition as fast as possible.
Posted: 26 Oct 2016 | 9:08 am
Posted: 26 Oct 2016 | 8:56 am
It’s unusual for a day to go by without finding some new variant of a known ransomware, or, what is even more interesting, a completely new one. Unlike the previously reported and now decrypted Xpan ransomware, this same-but-different threat from Brazil has recently been spotted in the wild. This time the infection vector is not a targeted remote desktop intrusion, but a more massively propagated malicious campaign relying on traditional spam email.
Since the infection is not done manually by the bad guys, their malware has a higher chance of being detected and we believe that is one of the reasons for them to have added one more level of protection to the code, resorting to a binary dropper to launch the malicious payload.
Given that this particular ransomware is fairly well known by now, instead of opting for the usual branding and marketing efforts in which most ransomware authors invest time, this group has decided to choose an unnamed campaign, showing only an email address for technical support and a bitcoin address for making the payment. It has become a kind of urban legend that if you can’t find something on Google, then it doesn’t exist.
Not very long ago, we saw the birth of truly autochthonous Brazilian ransomware, without much technical sophistication and mainly based on an open-source project. While there’s a long road ahead for local bad guys to achieve the level of the key players on the ransomware scene, this particular family is interesting to study since there have been versions in English, Italian, and now Brazilian Portuguese. Is this ransomware being sold as a commodity in underground forums with Brazilian crews just standing on the shoulders of giants? Or is this a regional operation just starting out?
As one of the very few ransomware variants that prepend a custom ‘Lock.’ extension to the encrypted files instead of appending it, the task of recognizing this malware is not particularly difficult. However, understanding its true origins could still be considered an ongoing debate.
If we trust that the first transaction corresponds to the very first victim, the campaign has probably been active since 2016-04-04 17:29:26 (April 4th, 2016). In reality, this is not exactly accurate. The timestamp of the original dropper shows that the sample was actually compiled at the beginning of October:
That would mean that the criminal behind the campaign might have had different ransomware campaigns running in the past, or is just using the same BTC wallet for more than his criminal deeds.
The dropper is protected by the popular .NET obfuscator SmartAssembly, as can be seen by the string “Powered by SmartAssembly 126.96.36.199”. Once executed, it tries to mask itself in the Alternate Data Stream of the NTFS file system in Windows:
It’s capable of disabling Windows LUA protection:
“HKLM\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\POLICIES\SYSTEM”; Key: “ENABLELUA”; Value: “00000000”
(cmd.exe /c %WINDIR%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
Reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f)
The mechanism used to write new information to the registry is quite unusual: it uses the official windows application ‘migwiz.exe’ in order to bypass the UAC screen, not requiring any action from the user to execute with elevated privileges.
The malware is able to do that by writing a library ‘cryptbase.dll’ to the same folder as the ‘migwiz.exe’ file. Then, as soon as it’s launched, the process will load this library, which has a WinExec call that will launch the command line provided by the parameter.
The reason why they are using MigWiz is because this process is one that is in Microsoft’s auto-elevate list, meaning it can be elevated without asking for explicit permission.
As a simple mean of information gathering, the dropper will read the name of the infected computer:
HKLM\SYSTEM\CONTROLSET001\CONTROL\COMPUTERNAME\ACTIVECOMPUTERNAME”; Key: “COMPUTERNAME
Moreover, it includes data stealer techniques, such as retrieving information from the clipboard, or while it’s being typed on the keyboard. Additionally it has the capability to reboot the user’s machine.
@4333be: push ebp
@4333bf: mov ebp, esp
@4333c1: sub esp, 14h
@4333c4: push ebx
@4333c5: mov ebx, dword ptr [ebp+08h]@4333c8: lea eax, dword ptr [ebp-04h]@4333cb: push eax
@4333cc: push 00000028h
@4333ce: call dword ptr [00482310h] ;GetCurrentProcess@KERNEL32.DLL
@4333d4: push eax
@4333d5: call dword ptr [0048202Ch] ;OpenProcessToken@ADVAPI32.DLL
@4333db: test eax, eax
@4333dd: je 0043341Eh
@4333df: lea ecx, dword ptr [ebp-10h]@4333e2: push ecx
@4333e3: push 00487D68h ;SeShutdownPrivilege
Finally, it drops and executes the file tmp.exe (corresponding hash B4FDC93E0C089F6B885FFC13024E4B9).
After the infection has been completed, as is usual in all ransomware families, the ransom note is shown. This time, it is written in Brazilian Portuguese and demanding 2000 BRL, which equates to around 627 USD or 1 BTC at the time of writing.
The bitcoin address provided (1LaHiL3vTGdbXnzyQ9omsYt8nFkUafXzK4) for payment shows total deposits for 1.89 BTC although many transactions have been made since the creation of this wallet. This is leading us to believe that either the criminal has been using the wallet for other purposes or they have bargaining with the victims and offering them a lower price, as depicted by the amount in each transaction.
The ransom note is very succinct, without giving any special payment URL or any other type of information. The victim will have to learn about bitcoin payments the hard way, and should they need support they can reach the criminals through a single email point of contact.
TODOS os seus arquivos foram BLOQUEADOS e esse bloqueio somente serão DESBLOQUEADOS
caso pague um valor em R$ 2000,00 (dois Mil reais) em Bitcoins
Após o pagamento desse valor, basta me enviar um print para o email
que estarei lhe enviando o programa com a senha para descriptografar/desbloquear o seus arquivos.
Caso o pagamento não seja efetuado, todos os seus dados serão bloqueados
permanentemente e o seu computador sera totalmente formatado
(Perdendo assim, todas as informações contidas nele, incluindo senhas de email, bancárias…)
O pagamento deverá ser efetuado nesse endereço de Bitcoin:
Para converter seu saldo em bitcoins acesse o site:
The growth of ransomware in Brazil has been nothing short of impressive, taking into consideration that during October 2016 alone the popular ransomware family Packed.NSIS.MyxaH.gen family grew by 287.96%, and another of the usual suspects Trojan-Ransom.Win32.CryptXXX.gen grew by 56.96%, (when compared to the previous month in each case.)
In 2016, the 3 most important families of ransomware have been Trojan-Ransom.Win32.Blocker, accounting for 49.63% of the total infections,
Trojan-Ransom.NSIS.Onion, 29.09%, and Trojan-Ransom.Win32.Locky, 3.99%.
Currently, Brazil is the eighth most affected country worldwide as far as ransomware infections go for this year, and ranked first in Latin America.
Compiled: Saturday, October 8 2016, 11:22:30 – 32 Bit .NET
Compiled: Sunday, January 29 2012, 21:32:28 – 32 Bit
Posted: 25 Oct 2016 | 12:57 am
Matt Decker from hybrid-cloudblog.com sent me this script he received via email and asked for help deobfuscating this so here we go…
Here’s the WSF file he sent me:
About half-way down the script, I come across this. Two variables should have caught your eye.
Doing a search for the first variable name, I end up at the variable “vista” which references that blob and then the function is immediately called.
To view the value of “vista”, I do this. I don’t want the script to run any further so I do a quit right after the popup.
And this is what I get. It shows several functions like reading and writing to a file and three conversion functions. This decrypts the download file which I’ll get to in a bit.
Searching for the other variable, brings us here. It’s inside of a for-loop and the variable “efioppocsonny5HORDA6” appears to be building up URLs then calling a function named “efioppocsonny5_a2”. Notice that the URLs are being passed in the first argument.
Now let’s search for this function. It’s going back up to here. Based on what’s in the function, it looks like it’s preparing and making AJAX calls.
So our goal is to see the URLs and block the HTTP request for now. Here’s the changes I make.
When I run it, I get the URLs one at a time.
If you want to pull down the payload then search for “.Run” and comment out that line so the payload won’t execute and interrupt our analysis.
Based on the script, it will download and save a file into the Temp folder, read it in, decode it, write it out to a DLL file, then execute it. However, this particular script doesn’t seem to have domains that answer so I have to find another script with live domains.
Here’s another one I got from VirusTotal Intelligence:
And make the same change.
This time I get the payload, the script decodes it then writes it out to a DLL file which turns out to be Locky/Odin.
Let’s have a look at the original downloaded file and the DLL file from the Temp folder. I wrote this program to analyze the files. I load up the binary files into each input box (only the first 1,024 bytes are read to save time).
Then I choose the “XOR” method as my first guess.
I get this result. Do you see a pattern in the output box?
How about now?
I can use Converter to XOR the original file using the same XOR pattern (converted to hex).
And get the same result as the original.
Now let’s see if we can find this in the script. Near the bottom there’s a long string that gets sent to the function VGRA3 (that function is from the blob we deobfuscated earlier). Then later when the payload is downloaded, the variable holding this key is used to XOR the file. It’s the same string.
But I did want to show you another related script I found. It’s basically the same as the one above, however, the JScript is inside of an HTML file. This is an important distinction because we have to deobfuscate this differently.
At the bottom of the script, we see that it’s functionally similar to the script we just looked at. Do you see that function call at the “if” statement? Let’s search for that. By the way, the blue arrow is pointing to the XOR key.
Here’s the function that takes in some arguments passed from the call at the bottom. The first argument is the URLs just like the previous script.
If I search for the variable name, we see that there’s two other variables prepending it.
Let’s see what these three variables are by adding the following line then have it stop running the rest of the script. Notice I have to use “alert” and “stop” instead of “WScript.Echo” and “WScript.Quit”.
Now I can execute the script by running it in IE. You can’t use another browser because this script uses an ActiveX control.
You can continue to alert on variables to better understand what it’s doing but you’ll find that it’s doing the same thing as the WSF script from above.
Posted: 22 Oct 2016 | 1:16 pm
The optimistic outlook is that the internet of things will be an enabling technology that will help make the people and physical systems of the world — health care, food production, transportation, energy consumption — smarter and more efficient.
The pessimistic outlook? Hackers will have something else to hack. And consumers accustomed to adding security tools to their computers and phones should expect to adopt similar precautions with internet-connected home appliances.
“If we want to put networked technologies into more and more things, we also have to find a way to make them safer,” said Michael Walker, a program manager and computer security expert at the Pentagon’s advanced research arm. “It’s a challenge for civilization.”
To help address that challenge, Mr. Walker and the Defense Advanced Research Projects Agency, or Darpa, created a contest with millions of dollars in prize money, called the Cyber Grand Challenge. To win, contestants would have to create automated digital defense systems that could identify and fix software vulnerabilities on their own — essentially smart software robots as sentinels for digital security.
A reminder of the need for stepped-up security came a few weeks after the Darpa-sponsored competition, which was held in August. Researchers for Level 3 Communications, a telecommunications company, said they had detected several strains of malware that launched attacks on websites from compromised internet-of-things devices.
The post Stepping up security for an Internet-of-Things World appeared first on CyberESI.
Posted: 18 Oct 2016 | 7:42 am
I saw a webcast done by Peter Ewane and Javvad Malik recently. The summary of what Peter had to say and Q&A follows; you can also view the recorded webcast.
Malware can be a lot of things. It can be a virus, a worm, spyware, a Trojan horse, or ransomware. It’s basically any malicious program that you would not want on your computer.
Lately it has become common to see malware hide in the Windows Registry. Why the Windows registry? The Windows registry is quite large and complex, which means there many places where malware can insert itself to achieve persistence. A good example of this behavior is Poweliks. Poweliks sets a null entry utilizing one of the built-in Windows APIs, ZwSetValueKey, which allows it to create a registry key with an encoded data blob. I’m not sure why the Windows API allows a null entry, but it does. This is one of the many ways that malware can utilize the Windows registry to hide out, autostart, and maintain persistence on many systems.
Here’s an OTX pulse on Poweliks: https://otx.alienvault.com/browse/pulses/?q=POWELIKS
Process injection is exactly what it sounds like. It is injecting some bits of code into a running process. Malware leverages process injection techniques to hide code execution and avoid detection by utilizing known “good” processes such as svchost.exe or explorer.exe. To inject itself into known good processes, malware writers use built-in Windows APIs. One of them is setting debug. When a process sets as debug, it gains access to many of the debug API calls, such as attaching to other processes and instructing processes to allocate additional memory. Once a process has allocate more memory, then a malicious process can inject whatever code it wishes into that process.
A great example of malware that uses process injection is Poison Ivy. Poison Ivy's process injection is one of my favorites not only because it is very well known but also because it is used in many campaigns, and does process injection slightly differently than other kinds of malware. When malware allocates a chunk of memory, normally that chunk of memory is “contiguous”, so at the end of a memory block, it will allocate another memory block and inject code there. Poison Ivy does what we call “sharding.” Instead of having one giant memory block, it has a whole bunch of tiny memory blocks split all over the process and sometimes in various processes. A great example of malware that uses process injection is Poison Ivy. Poison Ivy's process injection is one of my favorites not only because it is very well known but also because it is used in many campaigns, and does process injection slightly differently than other kinds of malware. When malware allocates a chunk of memory, normally that chunk of memory is “contiguous”, so at the end of a memory block, it will allocate another memory block and inject code there.
Here’s an OTX pulse on Poison Ivy: https://otx.alienvault.com/browse/pulses/?q=poison%20ivy
Another technique related to process injection is process hollowing. ‘Hollowing’ is a process where you take a known good process and start it in a suspended state. When that code is loaded and about to execute, you scoop some of the good code out (like with an ice cream scoop). Now there is available space where a bad guy can place whatever code they like, maybe change a few headers on the top and bottom to make everything seem okay, and then restart the execution process. As far as a user knows, this process looks like a normal system process started by Windows. It is therefore much more difficult for reverse engineers and memory forensics people to analyze.
Dridex is a very good example of a malware family that often uses process hollowing. Here’s an OTX pulse on Dridex:
Process List Unlinking is another key concept. A process is anything that is running on your computer, whether it be in user space or kernel space. Process List Unlinking involves a double-linked list that contains all “active” processes. It’s important because unlinking will result in a process being hidden from all “active” tools. This can be done using ZwSystemDebugControl() or by mapping \Device\PhysicalMemory. Inside the process list is a list of every single process that is running and inside the process object is forward-pointed and backwards-pointed into the process in front of it or the process behind it to make a double-linked list.
A Flink to the process before it and then Blink to the one in front of it effectively removes the process from the list. More advanced malware will take this a step further and after they remove that process from the list, they will also write over that bit of memory, so even with memory forensics you wouldn't be able to locate that process.
There are tools that security researchers can use to find hidden malicious code, such as
This is an example bit of code that somebody would use to unlink from the process list.
Malware can also hide by manipulating the DLL list. Just like the process list, a DLL list has a double-linked list that points to the DLL in front and behind, and again just like the process lists are APIs that can be called to rewrite entries in the DLL list, remove that DLL entry and wipe out that bit of memory to help hide the malware from memory forensics or from backup tools. This is used a lot in rootkit activity. Here’s a graphic explaining DLL lists:
Here we have another example of code used to unlink from the DLL list:
You can see where it is writing over the one in front, the one behind, and then wiping out the memory and the zero memory function call. One other thing to remember about DLL and process list linking is that all that can be done from the user space, so I don't need kernel-level administrative rights.
Kernel modules are the next level down. A kernel module is any of the modules that is loaded into the kernel. Like the DLL and process list, the kernel modules have their own list that can be queried with APIs and return every kernel module that is loaded. There are also debug APIs that can remove one DLL module from the list and zero it out. This is especially important because at the kernel level when something is zeroed out it makes it lot harder to find. This access is like ring zero access - definitely associated with rootkit activity. Generally, a piece of malware will execute in user space and then try a kernel-level exploit to get kernel administrative access; it then drops the main rootkit, which would then zero itself out inside the kernel module list process list. At this point, the malware is very well hidden and it will be very difficult to find.
How Kernel Module List Unlinking Works:
JAVVAD: So most malware sandboxes can’t deal with samples that remain dormant for a considerable amount of time before execution, such as Keranger. Have any new techniques been developed to overcome this?
PETER: Yes, there are a couple of different ways to overcome that. One way to tell malware remains dormant involves a certain amount system time. One way to manipulate that is to make the time go faster on the virtual machine, so every millisecond is actually ten minutes or every millisecond is actually five hours, defeating the dormant malware by waiting it out.
JAVVAD: How can AlienVault detect the malware hiding techniques that were described in the presentation?
PETER: Excellent question. One of the ways we can detect various hiding techniques described in the presentation, is based upon Windows logging. One example of such detection would be a processes acquiring the ability to utilize the built in Windows debug capabilities. There are known "Good" applications that use those functions, but outside of them it looks suspicious when other processes outside that circle utilize those debug capabilities which when then can alert on.
JAVVAD: Do you have anything to detect CryptoLocker or any other similar type family of ransomware?
PETER: Yes, we have correlation rules for CryptoLocker and various ransomware families.
JAVVAD: Is it anything specific that makes Ransomware different to look for compared to other sorts of malware, or is it pretty much the same techniques that you use?
PETER: These techniques are more about hiding. Ransomware generally is not very good at hiding, that is not its job. Its job is to be loud and in your face. So generally we can look for that being loud and in your face or any sort of network detector, so like it is connecting to known bad domains, etcetera.
JAVVAD: Is there a tool that can utilize OTX to scan a raw memory image file for IoCs?
PETER: What I would personally recommend is while you can't import memory images into OTX yet, you can use a tool such as Volatility to pull out IP and/or domains depending on what you want to scan, and then you can cross-reference with OTX based on the information that you pull up from the memory image.
JAVVAD: What is the general turnaround time between the AlienVault team capturing a sample of the zero-day attack and actually producing signatures?
PETER: That is hard to give an exact answer to because every bit of malware is different and every zero-day is different. Sometimes it can be a couple of hours, sometimes it may take longer than that.
JAVVAD: Yes. I will just add to that, actually. Last year, Adobe released a zero-day, and actually because the IoCs were being reused from previous campaigns, effectively we were blocking that zero-day three months prior to Adobe actually publicly announcing it. So it is not always the case that zero-days produce effects.
Peter Ewane is a security researcher at AlienVault. Follow him on Twitter https://twitter.com/eaterofpumpkin
Javvad Malik is the security advocate at AlienVault. Follow him on Twitter https://twitter.com/J4vv4D
Posted: 3 Oct 2016 | 6:00 am
Posted: 23 Aug 2016 | 9:19 pm