Beginning on Oct. 10, 2016, IBM X-Force detected a notable increase in Shellshock activity lasting four days. Given its prevalence over the last two years, we didn’t think we had seen the last of Shellshock. We are a little surprised, however, by its latest uptick in activity.
This spike saw nearly the same volume of Shellshock attacks as the one we observed prior to the malware’s two-year anniversary last month. The attacks in this latest wave, however, were sourced from only four U.S.-based IP addresses, whereas the previous spike in Shellshock activity originated from hundreds of unique IP addresses.
Just as quickly as they appeared, the attacks evaporated as of Oct. 14, 2016.
More Shellshock Attacks
As with September’s attacks, this more recent wave was designed to perform reconnaissance against distributed targets to find machines vulnerable to Shellshock. Targets were not concentrated in any specific geography — this was a global campaign spanning multiple industries.
The campaign — currently rated 10, indicating the highest level of risk — used the following four IP addresses:
The attack’s payload contained the following information:
:header_value=() { :;}; echo; echo “”39319c2bd3231f5c4a15e142faef5bf2″”
Unlike the September attacks, which used the Session Initiation Protocol (SIP) to determine exploitability, the October attacks used a unique identifier that looks suspiciously like an MD5 checksum, but it is not. Each individual attack thread is assigned a unique string that identifies the target as vulnerable to the Shellshock exploit. Exploitation is possible when the attacker sees the unique identifier echoed back into the attack tool.
For more information about the October wave of Shellshock attacks, see the IBM X-Force Exchange collection.
Patching the Broken Record
This may sound like a broken record by now, but if you have not patched your systems against this threat, we strongly advise doing so as soon as practical. The IBM X-Force Exchange vulnerability report contains an extensive list of references. This should provide you with the information you need to obtain the appropriate patches. Protocol analysis can provide another layer of security against these attacks.
Because the aforementioned IPs are registered to what appears to be a cloud provider, I’d be remiss if I didn’t point out the potential risks associated with cloud services. Companies must consider the risks of misuse of employee credentials, hijacked accounts and insecure interfaces or application program interfaces (API) when deciding whether to adopt a cloud solution. Security should be at the heart of any organization’s cloud strategy and design.
Manager, X-Force Strategic Threat Analysis, IBM