Monthly Archives: December 2017

Info Stealing: a new operation in the wild

Attack attribution is always a very hard work. False Flags, Code Reuse and Spaghetti Code  makes impossible to assert "This attack belongs to X". Indeed nowadays makes more sense talking about Attribution Probability rather then Attribution by itself. "This attack belongs to X with 65% of attribution probability" it would be a correct sentence.

I made this quick introduction because the following analysis would probably take the reader to think about specific attribution, but it wont be so accurate, so please be prepared to have not such a clear conclusions.

Today I'd like to show an interesting analysis of a quite new InfoStealer Malware delivered by eMail to many International Companies. The analysis shows up interesting Code Reuse capabilities, apparently originated by Japanese Attackers reusing an English Speaker Attacker source code. Again I have not enough artifacts to give attributions but only few clues as follows. In the described analysis, the original sample was delivered by (with high probability a compromised South Africa account) to one of my spamming email addresses.

The obtained sample is a Microsoft Word document within macro in it. The macros were heavily obfuscated by using four rounds of substitutions and UTF-8 encoding charsets (which, by the way, is super annoying). The following image shows the obfuscated macro code with UTF-8 charsets.

Stage 1: Obfuscation
 By using oletools and "tons" of cups of coffee (to be awake until late night to make recursive steps) I finally was able to extract the invoked command, showed in the following image.

Stage 1: Invoked Command
A fashionable powershell command drops and executes: hxxp:// Powershell seems to be a "must have" in contemporary Malware. Analyzing the "dropping" url and tracking down the time it is in "Index Of" mode (2017-0-13), I suspect it is not a compromised website rather a crafted web server or a compromised host of a dead company.

Dropping Web Site

By surfing on the Malware propagator web site I founded out many malicious executables (sees IoC section) each one showing up specific behaviors such as: password stealers, RAT and Banking Trojans. Even if the samples were developed for different targets, all of them shared the following basic behaviors:

  • Check for victims IP address before getting into Malicious activities (maybe related to targeted activities)
  • Install itself into auto execution path
  • Tries to fingerprint the target system (such as CPU, HD, Memory, Username, System, etc..)
  • Sniff for Keystrokes

I'd like to write a simple analysis for each found sample, but today time is not my friend, so let's focalize to one of the malicious samples. Let's get done the received sample by digging into the "second stage" dropped by the powershell "first stage" from After few seconds on second stage (off.exe) it became clear that it was a .NET software. By reversing the interpreted .NET language some clear text comments appeared interesting. Japanese language such as comments and variable names came out from static analysis. Let's have a look to them.

Stage 2: Apparently Japanese characters

While the sample pretends to be compiled from "Coca-Cola Enterprise" (maybe a target operation against Coca-Cola ? Or a targeted operation agains Coca-Cola Suppliers ? So why it ended up to my inbox ? Anyway ... ) google translator suggests me that Japanese characters are in text: such as the "Entry Point", "Class names" and "Function Names". 

Stage 2: Japanese Names and Self Encoding Structures

It was not hard to figure out that Stage 2 was auto-extracting bytes from itself (local variables) and saving them back to hard drive after having set up auto execution registry key on windows local registry.  The following image shows the xoring function used to decrypt converted bytes to the real payload. 

Stage 2: Xoring function to extract Stage 3

On my run, the xored payload took the name of GIL.exe; another .NET  executable. We are now facing the third stage. By analyzing the decompiled sample it became clear that:
  • The coding style was quite different from the previous stage (Stage 2)
  • The implementation style was different from the previous stage as well
  • The sample was interested on information about the user, the machine, the webservices on the PC and to many more windows specific parameters.
Stage 3:  New Language in Strings and Class names
Stage 3: New Code Style

By closely investigating Stage 3, the analyst would probably notice the heavy presence of "decorators", a different format in the definition style and last but not least the code composition. Everything looks like belonging to different single developers. The variable language, the comments structure and the general usage of terms, takes the analyst to believe in having found two different developers belonging to different cultures (maybe countries). Finally the malware looks for users, computes, and webservices informations and drops everything up to C2 by posting parameters to :

Following the principal IoC for the described threat.
  • Hash Stage 1:
    • 7f1860673de9b1c2e6f7d6963a499e8ba4e412a1
    • bf4a26c9e52a8cacc7afd7d95d197bff1e47fb00
  • Hash Stage 2:
    • ac55ee783f3ed0bd23eccd01040a128dc6dc7851
  • Hash Stage 3:
    • 6a38e4acd9ade0d85697d10683ec84fa0daed11c
  • Persistence: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\kij %APPDATA%\Roaming\kij\kij.exe
  • Dropping URL:
  • Command and Control:
  • Related hashes from harvesting Dropping URL:
    • 62c9d2ae7bafa9c594230c570b66ec2d4fa674a6
    • b15b69170994918621ceb33cb339149bdff5b065
    • 55abcfb85e664fbc8ad1cb8b60a08409c2d26caa
    • f843427e9b7890f056eaa9909a5103bba6ffb8fd
    • f2b81e66fcb1032238415b83b75b3fe8bf28247d
    • cab90f7c935d355172b0db123d20b6a7d1403f65
    • c1ba30d7adec6d545d5274f95943f787ad4c03e7
    • ed9959bb0087f2c985b603cee0e760f3e0faaab15
    • c93851627ffd996443f85d916f3dbedd70e0ff69
    • 144b34b4816062c2308a755273159e0460ffd604
    • 98293b80ccf312a8da99c2b5ca36656adebd0d0f 
    • 2875d1b54337b1c17c8f4cd5f6b2d579667ee3d9 
    • 0b4299ffb3f9aa59e19dd726e79d95365fe1d461
    • 46bb0b10d790a3f21867308e7dcdeb06784a1570
    • 0960726560a94fbbb327aa84244f9588a3c68be8 
    • a480a75c3af576e5656abadb47d11515a18a82be
    • 2ba809c53eda2a475b1353c34f87ce62b6496e16
    • 5b0c3071aa63e18aa91af59083223d3cceb0fa3c 
    • dc780bf338053e9c1b0fdf259c831eb8a2768169

As final thought I'd like to highlight the following key concept of that analysis:
  • From a single email, the analyst could discover attacker's assets, mapping them and disarming them (through IoC). 
  • The analyzed code shows apparent evidences to belonging to different groups of attackers.
  • The analyzed samples show code reuse. Code reuse is dangerous because it makes attackers more powerful and extremely quick to change Malware behavior.
Hope you enjoyed.

Happy New Year – Startup Security Weekly #67

This week, Rick Olesek and Rich Walchuck of CryptoniteNXT join us for an interview! In the article discussion, we talk about startups most likely to succeed, how to pitch your app to investors, and calculating your total addressable market! In the news, we have updates from Thales, Amazon, Convercent, ADT, and more on this episode of Startup Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

Merry Christmas – Paul’s Security Weekly #541

Bob Hillery, Co-Founder and Director of InGuardians joins us for an interview, and Kevin Finisterre, Principal of the Security Consultancy of Department 13 joins us to deliver the tech segment! In the news, Uber pays hacker to keep quiet, flaw in Intel processors allowing undetectable malware, Apple patches other High Sierra security holes, and more on this episode of Paul's Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

IcedID New Tricks: Where Banking Trojan meets Phishing

IcedID Expanding Target List

Although ransomware has been getting all the headlines in the news, banking trojans continue to be an issue.  New variants are constantly evolving and offering new risks. At UAB, we have been looking closely at banking trojans such as Ramnit, TrickBotIcedID and so on. Recently, Cliff Wilson, malware analyst at UAB malware lab, contributed in establishing that TrickBot is spamming. TrickBot was silent for the past week, so he was asked to take a dive in at IcedID banking trojan.

IcedID Banking Trojan

This analysis focuses on the malware sample with the hash:

This sample is identified by ESET as "Win32/Spy.Icedid.A", although many AV engines, including Ahn, Aegis, and Kaspersky, refer to it as being part of the Andromeda family.  As with most malware, most AV engines offer the meaningless identifier "Generic" such as AVG (Win32:Malware-Gen), McAfee (Generic  Trojan.i), Symantec (Trojan.Gen.2), TrendMicro (TROJ_GEN.R002C0WL517),

While testing this sample, we noticed the same behavior we have observed before: web injects and phishing pages on financial websites. During further analysis of the IcedID process and its web-injects, Cliff made an interesting observation.

The URL https[:]//financebankpay[.]com/ was found in the web-injects and contains dozens of ‘mock’ web pages and phishing pages to IcedID’s targeted sites. The pages we have observed in the past IcedID sample were present: pages for Discover, Citi, Chase, Amazon, Amex and few others. Several new pages were discovered, which we had not observed before. was purchased from Chinese registrar EraNet and hosted on a Russian IP address.  The WHOIS information was bogus, borrowing the name of a man from Texas, but saying he lived in the city of "Kileen" with the state "DK", using a throw-away email from "" for his WHOIS email address.

When visiting a targeted URL, the webinject was loaded by the malware by pulling a page from from one of the following paths, and presenting it as if it were content from the true brand.

cashpro  (a banking portal for Bank of America)
ktt_key  (Key Bank) 
live        (Microsoft email services)

A few examples of the new emulated pages with injected code are as follows.


Fig. 1: Login Page for Google Account
The google web-inject can be reached by trying to login through any Google service (Gmail, Hangouts, Youtube) when infected with IcedID



Fig. 2: Login Page for Outlook

US based banks


Fig 3. Stealing credit card details and PIN for a US bank

Fig. 4: Business Portal Login for US Based Bank

Additional findings

This sample, along with other recently tested IcedID samples exhibited these similar behaviors.
  • created the directory \onaodecan in \AppData\Local
  • created “sonansoct.exe” within this directory
  • soon after created a .TMP file within \AppData\Local\Temp
  • opened this file as a process, then closed the main process
  • this file was updated throughout the testing period
  • other .TMP files were also created, but not executed (further analysis of these files is needed)
  • any visited URL could be found in the memory strings of the .TMP process after visiting
Researchers will continue to provide regular and interesting updates about the different types of Banking Trojans floating in the wild. We need a consistent and combined effort from all the financial institutions to deal with such a malaise for the banking sector and end users.

Blog-ified Tweetstorm

I dumped this on Twitter as a tweetstorm, but it is worth sharing here in one place.

Those who have followed me for a while have probably noticed that I rarely get technical here anymore. My world, and world view have changed.

I still play with stuff, but it tends to be specific to the nice folks who pay me, or esoteric stuff for personal use. Or for @SecurityBSides networks and labs.

I believe that right now I can do more good by supporting our communities and the people in them (that means YOU) than by focusing on technology myself.

The past few years have not been fun for me. My wife had a 2.5 year battle with cancer which ended a year ago this Friday, I've spent the past year discovering what it means to be without her after 40 years together.

(Also, this "being single" thing is bizarre, now I get what you kids have been complaining about- but that's a story for another day, or a stand-up comedy set)

Thank you all for all of your words and acts of kindness, large and small. It has meant a great deal to me. I might not be here now if not for the support of more people than I can thank.

Yeah, I said that. There were days when I asked myself the question "Do I want to wake up tomorrow?". And there were times when the answer was "no". I never seriously considered acting on it, but yes, there were ugly days, and not just a few.

If I can repay the amazing support and kindness shown to me by making things less bad for others I'm all in.

Disclaimer: I am not a psychologist, therapist, doctor, or anything like that. That said, if you need someone to talk/vent/rant/cry to, I'll be here as much as I can. Really. Dealing with stress, burnout, anxiety, illness, or death: I'll do my best to be here for you.

I travel a lot and I'm not always available, so don't count on me for immediate responses. But count on me. And if I get overwhelmed, I'll back off until I can resume.

I'm not the only one to make an offer like this, find one of us or turn to professionals if you need more than a sympathetic ear.

The holidays are a time of happiness and joy for many people. But they are also unpleasant for many of us, so let's take care of each other this holiday season. And the rest of the year, too.

Now you smart kids get busy on the technology stuff.



Christmas Directories – Enterprise Security Weekly #73

This week, Paul and John talk about Active Directory insecurity, how to solve problems with endpoint detection and response, and how to fix authentication issues! In the news, we have updates from Flexera, Amazon, ExtraHop, and more on this episode of Enterprise Security Weekly!


Full Show Notes:


Visit for all the latest episodes!

Transitioning from Blue Team to Red Team

I moved from Desktop Supervisor to Network Security in 2000. I did Blue Team for two companies from 2000 until early this year. At that point I was given an opportunity to move to Red Team as the company's in-house penetration tester. Starting in a new discipline in Network Security is a daunting task after spending so many years in another area, but a couple of things already were in my favor. I had taken two Red Team oriented SANS courses and certified in both and I had been doing deep dive intrusion analysis for all those years. I was exposed to a lot of methodologies and exploits.

But defending isn't attacking, and the learning curve was (is) still very wide. Fortunately, there are shared areas of knowledge between being an intrusion analyst and a pen tester. If you're just breaking into network security, those areas will serve you well regardless of what direction you go (or change to in the future).

1. Linux

Linux is the operating system of choice for the majority of tools for both pen testing and intrusion analysis. There are some exceptions, tools you can only run on Windows, but that's a very small subset. The more Linux you learn, the better prepared you'll be to use whichever tool is the correct one for any given situation. Fortunately, there's more free (and excellent) self training on Linux than any other subject I know of. You don't need to spend thousands of dollars taking training courses or get a Linux certification; there are hundreds of sites that will teach you step by step. Of course, if you're fortunate enough to work for a company that wants you to do RedHat or Linux Foundation training and will pay for it, by all means do so. Certifications will help you both move up in your current position and, if you should need to or choose to, find a new position. Redhat is the most well known name and bigger companies will be running it because of their excellent support, but there are other good courses and certs you can obtain. But by all means, spin up a Linux machine and get in it and learn. The more you learn, the better off you'll be.

2. Scripting

You don't need to be a programmer to do either job, but learning some scripting skills will really help you. Whether it's Bash or a language like Python or Ruby or Perl, being able to create a script to do repetitive tasks is an immense time saver. Another advantage is that if the tool you need to use is written in a shell or a language you understand, you can open it and follow the logic to see what it does, or even modify it, tweak and customize it, to suit your unique purpose. Python is extremely popular right now so a lot of the tools being released are written in it. And it's one of the easiest languages to learn. And, like Linux, there are a lot of free resources to learn Python.

3. Networking

Learning about networking is essential, whether you're running exploits or investigating an attack. Without a basic knowledge of how networks work and the components that comprise them, you'll be confused and lost in a short amount of time. You don't have to be a packet jockey to do intrusion analysis (the vast majority of attacks have switched from server side to client side anyways), but you will need to be able to follow the flow of traffic and understand the protocols in use to get a clear picture of the attack and whether it was successful or not. From a pentester's vantage point, you need to understand the network you're attacking to find the correct target and use the correct tool, and to be able to understand the responses your attack receives. If it's unsuccessful, you need to be able to determine why and what to change. The more you understand, and it's a vast and complex field, the better off you'll be.

Finally, whatever direction you go in, invest in yourself learning. The hardest part of doing that is your free time. You're not going to be able to learn everything you need to know while at your job or in a weeks worth of training once a year. If you want to advance, you'll need to sacrifice some of your own free time to study and learn. If it's something you naturally enjoy learning about, it won't be too big a burden. If you absolutely hate studying the subject matter, maybe it's time to step back and reassess if this is really what you want to do the rest of your life.

Good luck in your career, and Merry Christmas and have a Blessed New Year.

How to securely erase your Android device in 4 steps

It's an inevitable moment in the smartphone-owning cycle, the point at which a newer, shinier model comes along and your trusty old device is no longer needed.

Maybe your company bought you a new Android phone. Maybe your old one was getting too slow. Or maybe you just love electronics and couldn't resist the lure of whatever sexy new Android device your favorite manufacturer started selling.

Whatever the case, it's common nowadays to find yourself with an extra phone. And while there are plenty of practical uses for an old Android device, there's also a time when the best choice is to sell, donate, or otherwise pass it along.                                                                            

To read this article in full, please click here

How to securely erase an iPhone in just 3 steps

There are two main scenarios in which erasing an iPhone is called for: Either you’re getting a new phone, or the one you have is having problems.

The most common reason involves iPhone owners who trade up to newer models, usually in the fall after Apple unveils its latest line-up. Let's say you buy the new iPhone X and then plan to trade in or sell your older iPhone 7; you’ll need to make sure your data is no longer present once the old phone leaves your possession.

To read this article in full, please click here

Hack Naked News #154 – December 19, 2017

Michael reports on a suspected North Korea Ransomware attack, Kaspersky federal software ban, compelled passwords, and 1 in 3 IT professionals looking for new jobs! Jason Wood of Paladin Security joins us for the expert commentary on Bitcoin, and more on this episode of Hack Naked News!


Full Show Notes:


Visit for all the latest episodes!

Don’t be a security snob. Support your business team!

Don't be a security snob. Support your business team!

There have been many a times that access controls have been discussed in the meetings related to web development. With an interconnected world of APIs it is very important to understand the authentication of these end-points. One of the best approach I always vouch for is mutual authentication on SSL certificates (or 2 way SSL). Most of the times it is viable but it fails when either of party couldn't support it (hence not mutual). So, what to do when the business can't implement your "security requirement"?

The role of security is not to hinder the business, but to support it. It has to act as a pillar, and not a tollgate. We all know, that's audit!

Are you a security snob?
The rules/ regulations made by us, auditors and regulators are to make sure the architecture, implementation and roll-out is secure, and the information is tightly controlled. It is in no manner adding to the miseries of developers at the last stage of go-live. The security requirements must be clear right from the design phase. There must be a security architect appointed to work in accordance with the industry standards, and security nitty-gritties. Sometimes the security team gets to know that few important implementations have not been considered and now the project is at final stage. What should the security do - Shall it take business to the grinding halt? Shall it take the developers back to drawing board? No and no! Don't be a snob!

Look forward, and figure out the workarounds; strong mitigations steps to find a way to lower the risk. As long as you can lower the risk to minimum by using WAF, access controls, and white-listing etc. the business can make a plan to "fix" it in the next release. Make sure business understands the risk - brand or financial, and then if the risk is too high - involve the "C" suite executives, but support the business instead of bashing them with - you didn't do this, or that. It is counter-productive and doesn't help any party.

In most cases "business" accounts for the IT security paychecks and it's your (security team) job to avoid it looking like an overhead, but an investment!
IT security is NOT generating money. So don't point fingers, but hold hands!

Now, in the case of mutual authentication - what if the 2-way SSL is not available? Is IP white-listing a possible option with API credentials? Yes, if the IP is not shared by the whole network & the traffic is over secure channel. It's a strong measure to apply and restrict the participating parties to talk 1:1 on an encrypted channel. But then, I have been asked what if there is IP spoofing? Come'on guys! IP spoofing doesn't work the way you think. It's a TCP handshake; how do you expect the handshake to succeed when the IP doesn't ACK the SYN-ACK? Rememeber, the "actual IP" is not expecting the SYN-ACK & traffic will not go to the "malicious IP". So, IP spoofing over Internet is out of picture.

As a security specialist, try to understand that there are various ways to strengthen the security without being a pain in the ass. There are ways to implement compensatory controls; making sure the traffic is encrypted, access controls are tightly restricted, and risk is lowered significantly. If you can do this, you can definitely help business go live, and give them time to manage the security expectations more constructively.

Cheers, and be safe.

aPAColypse now: Exploiting Windows 10 in a Local Network with WPAD/PAC and JScript

by Ivan Fratric, Thomas Dullien, James Forshaw and Steven Vittitoe


Many widely-deployed technologies, viewed through 20/20 hindsight, seem like an odd or unnecessarily risky idea. Engineering decisions in IT are often made with imperfect information and under time pressure, and some oddities of the IT stack can best be explained with “it seemed like a good idea at the time”. In the personal view of some of the authors of this post, WPAD (“Web Proxy Auto Discovery Protocol” - and more specifically “Proxy Auto-Config”), is one of these oddities.

At some point in the very early days of the Internet - prior to 1996 - engineers at Netscape decided that JavaScript was a good language to write configuration files in. The result was PAC - a configuration file format that works as follows: The browser connects to a pre-configured server, downloads the PAC file, and executes a particular Javascript function to determine proper proxy configuration. Why not? It certainly is more expressive and less verbose than (let’s say) XML, and seems a reasonable way to provide configurations to many clients.

PAC itself was coupled with a protocol called WPAD - a protocol that makes it unnecessary for the browser to have a pre-configured server to connect to. Instead, WPAD allows the computer to query the local network to determine the server from which to load the PAC file.

Somehow this technology ended up being an IETF draft which expired in 1999, and now, in 2017, every Windows machine will ask the local network: “Hey, where can I find a Javascript file to execute?”. This can happen via a number of mechanisms: DNS, WINS, but - perhaps most interestingly - DHCP.

In recent years, browser exploits have mutated from being primarily DOM-oriented to targeting Javascript engines directly, so the mere mention that we can get Javascript execution over the network without the browser was motivating. An initial investigation revealed that the JS Engine responsible for executing these configuration files was jscript.dll - the legacy JS Engine that also powered IE7 and IE8 (and is still reachable in IE11 in IE7/8 compatibility mode if appropriate script attributes are used). This is both good and bad - on the one hand, it means that not every Chakra bug is automatically a local network remote attack, but on the other hand, it means that some pretty old code will be responsible for executing our Javascript.

Security researchers have previously warned about the dangers of WPAD. But, as far as we know, this is the first time that an attack against WPAD is demonstrated that results in the complete compromise of the WPAD user’s machine.

Windows is certainly not the only piece of software that implements WPAD. Other operating systems and applications do as well. For example Google Chrome also has a WPAD implementation, but in Chrome’s case, evaluating the JavaScript code from the PAC file happens inside a sandbox. And other operating systems that support WPAD don’t enable it by default. This is why Windows is currently the most interesting target for this sort of attack.

Web Proxy Auto-Discovery

As mentioned above, WPAD will query DHCP and DNS (in that order) to obtain a URL to connect to - apparently LLMNR and Netbios can also be used if no response from DNS is available. Some peculiarities of WPAD-over-DNS enable surprising attack vectors.

Attack scenario: Local network via DHCP

In the most common scenario, a machine will query the local DHCP server using option code 252. The DHCP server replies with a string - like “http://server.domain/proxyconfig.pac”, which specifies a URL from which the configuration file should be fetched. The client then proceeds to fetch this file, and execute the contents as Javascript.
In a local network, an attacker can simply impersonate the DHCP server - either by ARP games or by racing the legitimate DHCP. The attacker can then provide a URL where the malicious Javascript file is hosted.

Attack scenario: Remote over the internet via privileged position and DNS

Aside from the local-network attack scenario, the fact that lookup for WPAD may also happen via DNS creates a secondary attack scenario. Many users configure their computers to perform DNS lookups against one of the public, globally visible DNS servers (such as,, and In such a scenario, a machine will send DNS queries (such as wpad.local) to the server which sits outside of the local network. An attacker in a privileged position on the network (e.g. a gateway, or any other upstream host) can monitor the DNS queries and spoof a reply, directing the client to download and execute a malicious Javascript file.

Setups like these seem to be common - according to this Wikipedia entry, a nontrivial proportion of the traffic that the DNS root servers see are .local requests.

Attack scenario: Remote over the internet via malicious wpad.tld

A particular oddity of WPAD is that it recursively walks the local machine name to find domains to query. If a machine is called “”, the following domains are supposedly queried in order:


This has (according to this Wikipedia entry) in the past led to people registering and redirecting traffic to an online auction site. Further quoting from that entry:

Through the WPAD file, the attacker can point users' browsers to their own proxies and intercept and modify all of WWW traffic. Although a simplistic fix for Windows WPAD handling was applied in 2005, it only fixed the problem for the .com domain. A presentation at Kiwicon showed that the rest of the world was still critically vulnerable to this security hole, with a sample domain registered in New Zealand for testing purposes receiving proxy requests from all over the country at the rate of several a second. Several of the wpad.tld domain names (including COM, NET, ORG, and US) now point to the client loopback address to help protect against this vulnerability, though some names are still registered (
Thus, an administrator should make sure that a user can trust all the DHCP servers in an organisation and that all possible wpad domains for the organisation are under control. Furthermore, if there's no wpad domain configured for an organisation, a user will go to whatever external location has the next wpad site in the domain hierarchy and use that for its configuration. This allows whoever registers the wpad subdomain in a particular country to perform a man-in-the-middle attack on large portions of that country's internet traffic by setting themselves as a proxy for all traffic or sites of interest.

The IETF draft, on the other hand, explicitly asks for clients to only allow “canonical” (e.g. non-top-level domains). We have not investigated to what extent clients implement this, or if second-level domains (such as are the culprit in the historical cases of traffic redirection.

Either way: Bugs in the Javascript engine under consideration can be exploited remotely via the internet if one manages to register wpad.$TLD for a given organization’s TLD, provided said TLD is not explicitly blacklisted by the client implementation. Given that the IETF draft from 1999 refers to a list of TLDs from 1994 (RFC1591), it is unlikely that clients have been updated to reflect the proliferation of new TLDs.

Our attempts to register$TLD for a variety of TLDs were not (yet) successful.


We spent some time looking for bugs in jscript.dll and employed both manual analysis and fuzzing. JScript initially posed some challenge because a lot of “features” useful for triggering bugs in JavaScript engines can’t be used in JScript, simply due to it being too old to support them. For example:

  • There are no multiple arrays types (int array, float array etc.). Thus confusing one array type for another is not possible.
  • There are not as many optimizations (“fast paths”) as in the newer, faster JavaScript engines. These fast paths are often the source of bugs.
  • It is not possible to define a getter/setter on a generic JavaScript object. It is possible to call defineProperty but only on DOM objects which doesn’t work for us as there won’t be a DOM in the WPAD process. Even if there were, a lot of JScript functions will simply fail when called on a DOM object with a message “JScript object expected”.
  • It is impossible to change an object’s prototype once it is created (i.e. there is no “__proto__” property).

However, JScript does suffer from more “old-school” vulnerability classes such as use-after-free. JScript’s garbage collector is described in this old MSDN article. JScript uses a non-generational mark-and-sweep garbage collector. Essentially, whenever a garbage collection is triggered, it marks all the JScript objects. Then it scans them starting from a set of “root” objects (sometimes also referred to as “scavengers”) and clears the mark from all the objects it encounters. All the objects that are still marked get deleted. One recurring problem is that local variables on the stack aren’t added to the list of root objects by default, meaning that a programmer needs to remember to add them to the garbage collector’s root list, especially if those variables refer to objects that can be deleted during the function’s lifetime.

Other possible types of vulnerabilities include buffer overflows, uninitialized variables etc.

For fuzzing, we used the grammar-based Domato fuzzing engine and wrote a new grammar specifically for JScript. We identified interesting built-in properties and functions to add to the grammar by looking at EnsureBuiltin methods of various JScript objects. The JScript grammar has been added to the Domato repository here.

Between fuzzing and manual analysis we identified seven security vulnerabilities. They are summarized in the table below:

Vulnerability class
Vulnerabilities affecting IE8 mode
Vulnerabilities affecting IE7 mode
Heap overflow
Uninitialized variable
Out-of-bounds read

At the time of publishing this blog post, all the bugs have been fixed by Microsoft.

The table breaks down the vulnerabilities by class and compatibility mode required to trigger them. JScript in WPAD is equivalent to running a script in IE7 compatibility mode, which means that, although we found 7 vulnerabilities, “only” 5 of them can be triggered in WPAD. However, the other vulnerabilities can still be used against Internet Explorer (including IE11) when put into IE8 compatibility mode by a malicious webpage.


Understanding JScript VARs and Strings

Since in the remainder of this blogpost we’re going to talk about JScript VARs and Strings a lot, it is useful to describe these before going deeper into how the exploits work.

JScript VAR is a 24-byte (on 64-bit builds) structure that represents a JavaScript variable and is essentially the same as the VARIANT data structure described in this MSDN article. In most cases (sufficient to follow the exploit) its memory layout looks like this:

Variable type, 3 for integer, 5 for double, 8 for string etc.
Depending on the type, either an immediate value or a pointer
Unused for most types

For example, we can represent a double precision number by a VAR that has 5 written in the first 2 bytes (indicating the double type), followed by an actual double value at offset 8. The last 8 bytes are going to be unused but they are going to be copied around if a value of another VAR is copied from this VAR.

A JScript string is a type of VAR that has the type 8 and a pointer at offset 8. The pointer points into a BSTR structure described here. On 64-bit builds BSTR layout looks like this:

String length in bytes not counting the null character at the end
String characters (16-bit) followed by a null character

A String VAR points directly to the character array, which means that, to obtain a String's length, the pointer needs to be decremented by 4 and the length read from there. Note that BSTRs are handled by OleAut32.dll and are allocated on a separate heap (i.e. a different heap than is being used for other JScript objects).

Freeing of BSTRs is also different than for most objects because, instead of directly freeing a BSTR, when SysFreeString is called, it first puts a string in a cache controlled by OleAut32.dll. This mechanism is described in detail in Heap Feng Shui in JavaScript.

Stage 1: Infoleak

The purpose of the infoleak will be to obtain the address of a string in memory whose content we fully control. We won’t be leaking any executable module addresses at this point, that will come later. Instead, the goal is to defeat high-entropy heap randomization and make the second stage of the exploit reliable without having to use heap spraying.

For the infoleak we’re going to use this bug in RegExp.lastParen. To understand the bug let’s first take a closer look at the memory layout of jscript!RegExpFncObj which corresponds to the JScript RegExp object. At offset 0xAC RegExpFncObj contains a buffer of 20 integers. Actually these are 10 pairs of integers: the first element of the pair is the start index into the input string and the second element is the end index. Whenever RegExp.test, RegExp.exec or with a RegExp parameter encounter a capturing group (parentheses in the RegExp syntax), the start and end index of the match are stored here. Obviously in the buffer there is space for only 10 matches, so only the first 10 matches are stored in this buffer.

However, if RegExp.lastParen is called and there were more than 10 capturing groups, RegExpFncObj::LastParen will happily use the number of capturing groups as an index into the buffer, leading to out-of-bounds read. Here is a PoC:

 var r= new RegExp(Array(100).join('()'));

The 2 indices (let’s call them start_index and end_index) are read outside the bounds of the buffer and can thus be made arbitrarily large. Assuming this first out-of-bounds access doesn’t cause a crash, if the values in those indices are larger than the length of the input string, then a second out-of-bounds access is going to occur which allows us to read a outside the bounds of the input string. The string content read out-of-bounds like this is going to be returned to the caller in a String variable where it can be examined.

This second out-of-bounds read is what we’re going to use, but first we need to figure out how to get controlled data into start_index and end_index. Fortunately, looking at the layout of RegExpFncObj, there is data we control after the end of the index buffer: RegExp.input value. By setting RegExp.input to an integer value and using a RegExp composed of 41 sets of empty parentheses, when  RegExp.lastParen gets called, start_index is going to be 0 and the end_index is going to be whatever value we wrote to RegExp.input.

If we make an input string adjacent to a freed string, then by reading after the bounds of input string, we can obtain the heap metadata such as the pointers to the other free heap segments (Left, Right and Parent node in the red-black tree of heap chunks, see Windows 10 Segment Heap Internals for more information). Image 1 shows the relevant objects at the moment of infoleak.

Image 1: Heap infoleak layout

We are using 20000 bytes-long strings as input in order for them not to be allocated on the Low Fragmentation Heap (LFH can only be used for allocations of 16K bytes and smaller) since the heap metadata for the LFH is different and does not include useful pointers in Windows 10 Segment Heap. Additionally, LFH introduces randomness that would affect our ability to place the input string next to a freed string.

By reading the heap metadata out of the returned string, we can obtain an address of a freed string. Then, if we allocate a string of the same size as the freed string, it might be placed at this address and we achieved our goal, that is we know the address of memory of a string whose content we control.

The whole infoleak process looks like this:

  1. Allocate 1000 10000-character strings (note: 10000 characters == 20000 bytes).
  2. Free every second one.
  3. Trigger the info leak bug. Use one of the remaining strings as an input strings and read 20080 bytes.
  4. Analyze the leaked string and obtain the pointer to one of the freed strings.
  5. Allocate 500 strings of the same length as the freed strings (10000 characters) with a specially crafted content.

The content of the specially crafted strings is not important at this stage, but will be important in the next one, so it will be described there. Also note that, by examining heap metadata, we can easily determine which heap implementation the process is using (Segment Heap vs NT heap).

Images 2 and 3 show heap visualization created using Heap History Viewer at the time around the infoleak. Green stripes represent allocated blocks (occupied by strings), grey stripes represent allocated blocks that are then freed by later allocated again (the stings we free and then reallocate after triggering the infoleak bug) and the white stripes represent data that is never allocated (guard pages). You can see how strings get allocated as the time passes, then half of them are freed (grey ones) and sometime later get allocated again (the stripes become green).

We can see that there are going to be guard pages after every 3 allocations of this size. Our exploit is never actually going to touch any of these guard pages (it reads too little data past the end of the string for that to occur) but in ⅓ of the cases there won’t be a free string after the input string for the infoleak so the expected heap metadata will be missing. We can, however, easily detect this case and either trigger the infoleak bug using another input string or silently abort the exploit (note: we didn’t trigger any memory corruption up to this point).

Image 2: Heap Diagram: Showing the evolution of the heap over time
Image 3: Step-by-step illustration of leaking a pointer to a string.

Stage 2: Overflow

In stage 2 of the exploit we’re going to use this heap overflow bug in Array.sort. In case the number of elements in the input array to Array.sort is larger than Array.length / 2, JsArrayStringHeapSort (called by Array.sort if a comparison function isn’t specified) is going to allocate a temporary buffer of the same size as the number of elements currently in the array (note: can be smaller than array.lenght). It is then going to attempt to retrieve the corresponding elements for every array index from 0 to Array.length and, if that element exists, add it to the buffer and convert to string. If the array doesn’t change during the lifetime of JsArrayStringHeapSort, this will work fine. However, JsArrayStringHeapSort converts array elements into strings which can trigger toString() callbacks. If during one of those toString() callbacks elements are added to the array where they were previously undefined, an overflow is going to occur.

To understand the bug and its exploitability better let’s take a closer look at the structure of the buffer we’ll overflow out of. It is already mentioned that the array will have the same size as the number of elements currently in input array (to be exact, it is going to be number of elements + 1). Each element of the array is going to be 48 bytes in size (in a 64-bit build) with the following structure:

Pointer to a string VAR after the original VAR at offset 16 is converted to string
Index (int) of the current element
VAR holding the original array element
int 0 or 1 depending on the type of VAR at offset 16

During JsArrayStringHeapSort, each element of the array with index < array.length is retrieved, and if the element is defined the following happens:

  1. The array element is read into VAR at offset 16
  2. The original VAR is converted into a string VAR. A pointer to the string VAR is written at offset 0.
  3. At offset 8, the index of the current element in array is written
  4. Depending on the original VAR type, 0 or 1 is written at offset 40

Looking at the structure of the temporary buffer, we don’t control a lot of it directly. If an array member is a string, then at offsets 0 and 24 we’re going to have a pointer that, when dereferenced, at offset 8 contains another pointer to the data we control. This is, however, one level of indirection larger than what would be useful to us in most situations.

However, if a member of array is a double precision number, then at offset 24 (corresponding to offset 8 into the original VAR) the value of that number is going to be written and it is directly under our control. If we create a number with the same double representation as the pointer obtained in Stage 1, then we can use our overflow to overwrite a pointer somewhere after the end of the buffer with a pointer to the memory we directly control.

Now the question becomes, what can we overwrite in this way to advance the exploit. One of the possible answers presents itself if we take a closer look at how Objects work in JScript.

Each Object (more specifically, a NameList JScript object) is going to have a pointer to a hashtable. This hashtable is just an array of pointers. When a member element of an Object is accessed, a hash of the name of the element is computed. Then, a pointer at the offset corresponding to the lowest bits of the hash is dereferenced. This pointer points to a linked list of object elements and this linked list is traversed until we reached an element with the same name as the requested element. This is shown in image 4.

Image 4: JScript Object element internals

Note that, when the name of the element is less than 4 bytes, it is stored in the same structure as the VAR (element value). Otherwise, there is going to be a pointer to the element name. Name lengths <=4 are sufficient for us so we don’t need to go into the details of this.

An Object hashtable is a good candidate to overwrite because:

  • We can control which elements of it are dereferenced by accessing the corresponding object members. Elements we overwrite with data we don’t control will simply never be accessed.
  • We have limited control over the hashtable size by controlling how many members the corresponding object has. For example a hashtable starts with 1024 bytes, but if we add more than 512 elements to the object, the hashtable will be reallocated to 8192 bytes.
  • By overwriting a hashtable pointer with a pointer to data we control, we can create fake JScript vars in the data we control and access them simply by accessing the corresponding object members.

To perform the overwrite reliably we do the following:

  1. Allocate and free a lot of memory blocks with size 8192. This will turn on the Low Fragmentation Heap for allocation of size 8192. This will ensure that the buffer we are overflowing out of, as well as hashtable we are overflowing into will be allocated on the LFH. This is important because it means there will be no other allocations of other sizes nearby to spoil the exploit attempt (since an LFH bucket can only contain allocations of a certain size). This in turn ensures that we will be overwriting exactly what we want with high reliability.
  2. Create 2000 objects, each containing 512 members. In this state, each object has a hashtable of 1024 bytes. However, adding just one more element to one of these objects will cause its hashtable to grow to 8192 bytes.
  3. Add the 513 element to the first 1000 objects, causing 1000 allocations of 8192-byte hashtables.
  4. Trigger Array.sort with an array with length=300 and 170 elements. This allocates a buffer of size (170+1)*48=8208 bytes. Due to LFH granularity this object will be allocated in the same LFH bucket as 8192-byte hashtables.
  5. Immediately (in the toString() method of the first array element) add 513th element to the second 1000 objects. This makes us pretty certain that by now the sort buffer is neighboring one of the hashtables. In the same toString() method also add more elements to the array which will cause it to grow out-of-bounds.

Image 5 shows heap visualization around the address of the sort buffer (red line). You can see the sort buffer is surrounded by allocations of similar size which all correspond to Object hashtables. You can also observe the LFH randomness in the sense that subsequent allocations are not necessarily on subsequent addresses, however this makes no difference for our exploit.

Image 5: Heap visualization around the overflow buffer

As mentioned previously, we crafted our overflow in such a way that some of the hashtable pointers of an unlucky JScript object will get overwritten with pointers into the data we control. Now finally what exactly we put into this data comes into play: we crafted it in such a way that it contains 5 (fake) JavaScript variables:

  • Variable 1 just contains number 1337.
  • Variable 2 is of special type 0x400C. This type basically tells JavaScript that the actual VAR is pointed to by pointer at offset 8, and this pointer should be dereferenced before reading or writing this variable. In our case, this pointer points 16 bytes before Variable 1. This basically means that the last 8-byte qword of Variable 2 and the first 8-byte qword of Variable 1 overlap.
  • Variable 3, Variable 4 and Variable 5 are simple integers. What is special about them is that they contain numbers 5, 8 and 0x400C in their last 8 bytes, respectively.

The state of the corrupted Object after the overflow is shown in image 6.

Image 6: State of objects after the overflow. Red areas indicate where the overflow occurred. Each box in the bottom row (except those marked as ‘...’) corresponds to 8 bytes. Data contained in ‘...’ boxes is omitted for clarity

We can access Variable 1 by simply accessing the corrupted object at the correct index (let’s call it index1) and similarly for Variables 2-5. In fact, we can detect which Object we corrupted by accessing index1 of all objects and seeing which now has the value 1337.

Overlapping Variable 1 and Variable 2 has the effect that we can change the type (first WORD) of Variable 1 into 5 (double), 8 (string) or 0x400C (pointer). We do this by reading Variable 2, 3 or 4 and then writing the read value into Variable 2. For example the statement

corruptedobject[index2] = corruptedobject[index4];

Has the effect that the type of Variable 1 will be changed into a String (8), while all other fields of Variable 1 will remain unchanged.

This layout gives us several very powerful exploitation primitives:

  • If we write some variable that contains a pointer into Variable 1, we can disclose the value of this pointer by changing the type of Variable 1 to double (5) and reading it out
  • We can disclose (read) memory at an arbitrary address by faking a String at that address. We can accomplish this by first writing a double value corresponding to the address we want to read into Variable 1 and then changing the type of Variable 1 toString (8).
  • We can write to an arbitrary address by first writing a numeric value corresponding to the address into Variable 1, then changing the type of Variable 1 to 0x400C (pointer) and finally writing some data to Variable 1.

With these exploit primitives, normally getting the code execution would be pretty simple, but since we’re exploiting Windows 10 we first need to bypass the Control Flow Guard (CFG).

Stage 3: CFG bypass

There are probably other known bypasses we could have used here, but it turns out that there are some very convenient bypasses (once attacker has a read/write primitive) specific to jscript.dll. We are going to exploit the facts that:

  • Return addresses are not protected by CFG
  • Some Jscript objects have pointers to the native stack

Specifically, each NameTbl object (in Jscript, all JavaScript objects inherit from NameTbl), at offset 24 holds a pointer to CSession object. CSession object, at offset 80 holds a pointer to near the top of the native stack.

Thus, with an arbitrary read, by following a chain of pointers from any JScript object, it is possible to retrieve a pointer to the native stack. Then, with an arbitrary write, it is possible to overwrite a return address, bypassing CFG.

Stage 4: Getting code execution as Local Service

With all the exploit elements in place, we can now proceed to getting the code execution. We are doing it in these steps:

  1. Read the address of jscript.dll from a vtable of any JScript object
  2. Read the address of kernel32.dll by reading the import table of jscript.dll
  3. Read the address of kernelbase.dll by reading the import table of kernel32.dll
  4. Scan kernel32.dll for rop gadgets we are going to need
  5. Get the address of WinExec from the export table of kernel32.dll
  6. Leak the stack address as explained in the previous section
  7. Prepare the ROP chain and write it to the stack, starting with a return address closest to our leaked stack address.

The ROP chain we are using looks like this:

[address of RET]  //needed to align the stack to 16 bytes
[address of POP RCX; RET] //loads the first parameter into rcx
[address of command to execute]
[address of POP RDX; RET] //loads the second parameter into rdx
[address of WinExec]

By executing this ROP chain we are calling WinExec with a command we specified. For example, if we run the command ‘cmd’ we are going to see a command prompt being spawned, running as Local Service (the same user WPAD service runs as).

Unfortunately, from a child process running as Local Service, we can’t talk to the network, but what we can do is drop our privilege escalation payload from memory to a disk location Local Service can write and execute it from there.

Stage 5: Privilege escalation

While the Local Service account is a service account, it doesn’t have administrative privileges. This means the exploit is quite limited in what it can access and modify on the system, especially to persist after exploitation or after the system has been rebooted. While there’s always likely to be an unfixed privilege escalation in Windows we don’t need to find a new vulnerability to escalate our privileges. Instead we can abuse a built-in feature to escalate from Local Service to the SYSTEM account. Let’s look at the privileges that the service account for WPAD has been granted:

Image 7: Service Access Token’s Privileges showing Impersonate Privilege

We’ve only got three privileges, but the highlighted privilege, SeImpersonatePrivilege is important. This privilege allows the service to impersonate other users on the local system. The reason the service has impersonate privilege is it accepts requests from all users on the local system and might need to perform actions on their behalf. However, as long as we can get an access token for the account we want to impersonate we can get the full access rights of the token’s user account, including SYSTEM which would give us administrator rights on the local system.

Abusing impersonation is a known issue with the Windows security model (you can find more details by searching for Token Kidnapping). Microsoft have tried to make it harder to get an access token for a privileged user but it’s virtually impossible to close all possible routes. For example, James discovered a vulnerability in Windows’ implementation of DCOM which allows any user to get access to a SYSTEM access token. While Microsoft fixed the direct privilege escalation vulnerability they didn’t, or perhaps couldn’t, fix the token kidnapping issue. We can abuse this feature to capture the SYSTEM token, impersonate the token, then completely compromise the system, such as installing a privileged service.

There’s an existing implementation of the token kidnapping via DCOM (RottenPotato) however the implementation was designed for use with the Metasploit framework’s getsystem command which we’re not using. Therefore, we implemented our own simpler version in C++ which directly spawns an arbitrary process with a SYSTEM token using the CreateProcessWithToken API. As a bonus we were able to compile it to an executable of 11KiB in size, much smaller than RottenPotato, which made it easier to drop to disk and run from the ROP payload.

Tying it all together

When the WPAD service queries for the PAC file, we serve the exploit file which exploits the WPAD service and runs WinExec to drop and execute the privilege escalation binary. This binary then executes a command (hardcoded ‘cmd’ in our case) as SYSTEM.

The exploit worked pretty reliably in our experiments, but it is interesting to note that a 100% reliable exploit isn’t required - if the exploit crashes the WPAD service, a new instance is going to get spawned when a client makes another request from WPAD service, so an attacker can just try again. There will be no indication in the UI that the WPAD service has crashed, although Window Error Reporting will likely pick up the crash and report it to Microsoft, provided that the user didn’t disable it.

In fact, our exploit doesn’t clean up gracefully and will crash the WPAD service once it runs its payload, so if we keep serving the exploit PAC file after the service has been exploited, it will just get exploited again. You can see the effect of that in Image 7, which was taken after leaving the exploit server running for some minutes and making a lot of HTTP requests in the victim machine.

Image 7: Did we leave the exploit running for too long?

We’ll publish the exploit source code in the issue tracker shortly.


Executing untrusted JavaScript code is dangerous, and executing it in an unsandboxed process is even more so. This is true even if it’s done by a relatively compact JavaScript engine such as jscript.dll. We identified 7 security vulnerabilities in it and successfully demonstrated reliable code execution from local network (and beyond) against a fully patched (at the time of writing) Windows 10 64-bit with Fall Creators Update installed.

Since the bugs are now fixed, does this mean we are done and can go home? Unlikely. Although we spent a fair amount of time, effort and compute power on finding jscript.dll bugs, we make no claims that we found all of them. In fact, where there are 7 bugs, there is likely to be an 8th. So if something doesn’t change it is quite possible we’ll see a chain like this used in the wild someday (and that is, of course, optimistically assuming that attackers don’t have this capability already).

So, what can Microsoft do to make future attacks like this harder:

  • Disable WPAD by default. In fact, while the other operating systems support WPAD, Windows is the only one where it is enabled by default.
  • Sandbox the JScript interpreter inside the WPAD service. Since the interpreter needs to execute a JavaScript function with well defined inputs and return the output string, sandboxing it should be pretty straightforward. Given the simplicity of the input-output model, it would be great if Microsoft introduced a sandbox of comparable restrictiveness to seccomp-strict: Some processes really do not need more privileges than “receive a bit of data”, “perform a bit of computation”, “return a bit of data”.

In case you want to take action on your own, the only way to prevent this type of attack using new, currently unknown vulnerabilities, seems to be to completely disable the WinHttpAutoProxySvc service. Sometimes this can’t be done in the Services UI (“Startup type” control will be grayed out) due to other services depending on WPAD, but it can be done via the corresponding registry entry. Under “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc” change the value of “Start” from 3 (manual) to 4 (disabled).

These are some of the advices commonly found online when searching for “disabling WPAD” that did not work to prevent the attack in our experiments:

  • Turning off “Automatically detect settings” in Control Panel
  • Setting “WpadOverride” registry key
  • Putting “ wpad” in the hosts file (this is going to stop the DNS variant but likely not the DHCP variant)

Don’t Let An Auto-Elevating Bot Spoil Your Christmas

Ho ho ho! Christmas is coming, and for many people it’s time to do some online shopping.
Authors of banking Trojans are well aware of this yearly phenomenon, so it shouldn’t come as a surprise that some of them have been hard at work preparing some nasty surprises for this shopping season.

And that’s exactly what TrickBot has just gone and done. As one of the most prevalent banking malware for Windows nowadays, we’ve recently seen it diversify into attacking Nordic banks. We’ve blogged about that a couple of times already.

As usual, the Trojan is being delivered via spam campaigns. According to this graph, based on our telemetry, most spam was distributed between Tuesday afternoon and Wednesday morning:


The spam emails we’ve seen typically have a generic subject like “Your Payment – 1234”, a body with nothing but “Your Payment is attached”, and indeed an attachment which is a Microsoft Word document with instructions in somewhat poor English…


Clicking the button will not reveal any document content, but launch a macro that will eventually download and run the TrickBot payload.
Same old trick, but some people who have just bought a Christmas gift might still fall for it and end up with another ‘gift’ installed on their computer.

And that ‘gift’ is the most interesting part of this story. The newest payload underwent some changes which are, well, remarkable…


Since its initial appearance during Fall 2016, the actors have been actively developing the malware, and are constantly expanding and changing the targets. Here a short summary of the recently spotted changes:

  • Removed: banks in Australia, New Zealand, Argentina, Italy
  • Changed: a few Spanish, Austrian and Finnish targets are now found in the Dynamic Injection list (adding interception code to the actual web page) instead of using Static Injection (replacing the complete web page)
  • Added: new banks, particularly in France, Belgium and Greece.

Anti-sandbox checks

Up till now, we were not aware of any features in TrickBot that were checking if the malware is run in a virtual machine or a sandboxed environment used for automatic analysis. The new version has introduced a few simple checks against some known sandboxes by calling GetModuleHandle for the following DLLs:


(More info about every DLL can be found here)

If any of these modules are found, the payload just quits.

Interestingly, we have also found a few encrypted strings that seem to indicate detection of the Windows virtual machine images that Microsoft provides for web developers to test their code in Internet Explorer and Edge, however, these strings are not used anywhere (yet). Let’s see if the actors will expand their sandbox evasion attempts in a future version.



But we have saved the best for last. When the payload was running, we noticed that it didn’t run with user rights, as it always did before. Instead, it was running under the SYSTEM account, i.e. with full system privileges. There was no UAC prompt during the infection sequence, so TrickBot must have used an auto-elevation mechanism to gain admin rights.

A little search in the disassembly quickly revealed an obvious clue:


Combined with a few hard-coded CLSIDs …


… we found out that the actors have implemented a UAC bypass which was (as far as we are aware of) publicly disclosed only a few months ago. The original discovery is explained here:
And later implemented as a standalone piece of code, and most likely the main inspiration for the TrickBot coders:

In short: this bypass is a re-implementation of a COM interface to launch ShellExec with admin rights, and it is used in a standard Windows component “Component Manager Administrator Kit” to install network connections on machine level.

It works everywhere from Windows 7 up to the latest Windows 10 version 1709 with default UAC settings, and considering it’s basically a Windows feature, probably hard to address. In other words, perfect for usage in malware, and it wouldn’t surprise us if we’ll see the same bypass in more families soon.

Thanks to Päivi for the spam graph.


Check the Soundstage – Startup Security Weekly #66

In our article discussion, we discuss managing risk, defining moments for your customers, ditching PowerPoint for better apps, and planning communications to avoid pitfalls! In the news, we have updates from Simility, Upstream, ShieldX, Atos, Menlo Security, and more on this episode of Startup Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

Spread Your Vegemite – Paul’s Security Weekly #540

Joe Gray of the Advanced Persistent Security podcast joins us for an interview! Ed Skoudis of the SANS Institute joins us to discuss the SANS Holiday Hack Challenge and what he’s been up to in the cyber world! In the news, the team discusses on-demand webcasts, net neutrality, pen testing, and Vegemite with Joff!

Full Show Notes:

Visit for all the latest episodes!


Windscribe Pro review: It’s all about the extras

Windscribe in brief:

  • P2P allowed: Yes, on most servers
  • Number of servers: 321
  • Business location: Richmond Hill, Ontario, Canada
  • Number of country locations: 50
  • Cost: $49 billed annually

Metropolitan Toronto is something of a VPN hub these days. We’ve already looked at TunnelBear and recent Symantec acquisition SurfEasy, both based in Toronto. Now it’s time to look at Windscribe, a capable VPN based just outside of Canada’s largest city.

To read this article in full, please click here

Lessons learned from a Man-in-the-Middle attack

It’s become a widely accepted mantra that experiencing a cyber breach is a question of ‘when’ and not ‘if’. For Fox-IT ‘if’ became ‘when’ on Tuesday, September 19 2017, when we fell victim to a “Man-in-the-Middle” attack. As a result of the multi-layered security protection, detection and response mechanisms we had in place, the incident was both small and contained, but as a cyber security specialist it has made us look long and hard at ourselves. While the police investigation is still on-going, we are sharing details of this incident with the public now that we feel confident that most details are sufficiently clear. This is about who we are and what we do. We believe that ultimately in these cases, transparency builds more trust than secrecy and there are lessons to be learned, both good and bad, that we want to share.

So what happened?

In the early morning of September 19 2017, an attacker accessed the DNS records for the domain at our third party domain registrar. The attacker initially modified a DNS record for one particular server to point to a server in their possession and to intercept and forward the traffic to the original server that belongs to Fox-IT. This type of attack is called a Man-in-the-Middle (MitM) attack. The attack was specifically aimed at ClientPortal, Fox-IT’s document exchange web application, which we use for secure exchange of files with customers, suppliers and other organizations. We believe that the attacker’s goal was to carry out a sustained MitM attack.

Because we detected and addressed the breach quickly we limited the total effective MitM time to 10 hours and 24 minutes. In the scheme of the industry average time of detection of weeks this was a short exposure, but we couldn’t prevent the attacker from intercepting a small number of files and information that they should not have had access to. An important first step in our response was to contact Law Enforcement and share the necessary information with them to enable them to start a criminal investigation.

The incident unfolded as follows (all times are CEST):

Sept 16 2017 First reconnaissance activities against our infrastructure that we believe are attributable to the attacker. These included regular port scans, vulnerability scans and other scanning activities.
Sept 19 2017, 00:38 The attacker changed DNS records for domain at a third party provider.
Sept 19 2017, 02:02 Latest moment in time that we have been able to determine that still pointed to our legitimate ClientPortal server. This means that traffic destined for the ClientPortal was not being intercepted yet.
Sept 19 2017, 02:05-02:15 Maximum 10-minute time window during which the attacker temporarily rerouted and intercepted Fox-IT email for the specific purpose of proving that they owned our domain in the process of fraudulently registering an SSL certificate for our ClientPortal.
Sept 19 2017, 02:21 The actual MitM against our ClientPortal starts. At this point, the fraudulent SSL certificate for ClientPortal was in place and the IP DNS record for was changed to point to a VPS provider abroad.
Sept 19 2017, 07:25 We determined that our name servers for the domain had been redirected and that this change was not authorized. We changed the DNS settings back to our own name servers and changed the password to the account at our domain registrar. This change will have taken time to have full effect, due to caching and the distributed nature of the domain name system.
Sept 19 2017, 12:45 We disabled the second factor authentication for our ClientPortal login authentication system (text messages), effectively preventing users of ClientPortal from successfully logging in and having their traffic intercepted. Other than that, we kept ClientPortal functional in order not to disclose to the attacker that we knew what they were doing, and to give ourselves more time to investigate. At this point, the MitM against ClientPortal was still active technically, but would no longer receive traffic to intercept as users would not be able to perform two factor authentication and log in.
Sept 19 – Sept 20 2017 A full investigation into the incident was undertaken, along with notification of all clients that had files intercepted and the relevant authorities, including the Dutch Data Protection Authority. A police investigation was launched and is still ongoing. Based on the outcome of our investigation, we understood the scope of the incident, we knew that the attack was fully countered and we were prepared to re-enable two factor authentication on ClientPortal in order to make it fully functional again.
Sept 20, 15:38 ClientPortal fully functional again. Our internal investigation into the incident continued.

What kind of information did the attacker intercept?

As mentioned, the attacker was able to redirect inbound traffic to ClientPortal and emails going to the domain for a short period of time. At no stage did they have access to any external or internal Fox-IT system, or indeed system level access to our ClientPortal.

When investigating the attack, we made heavy use of our own technology. For all Fox-IT traffic, we employ CTMp network sensors to detect anomalies and alert us of attacks. All our sensors do full packet capture and this is what allowed us to determine precisely, beyond any doubt, which information was intercepted by the attacker, the timeline of the event and who was affected by the attack.

Because of this we know the following about the information that the attacker was able to intercept:

  • We know the following facts about the information that the attacker intercepted:
    1. Nine individual users logged in and their credentials were intercepted and all users were contacted immediately. Because we use two factor authentication, these credentials alone were not enough for the attacker to log in to ClientPortal.
    2. Twelve files (of which ten were unique) were transferred and intercepted.
      • Of these, three files were client confidential in nature, none were classified as state secret. Files classified as state secret are never transferred through our ClientPortal.
      • Other files were in the public domain and not confidential.
      • All affected clients in respect of these files were contacted immediately.
    3. One mobile phone number was intercepted and this person was informed.
    4. A subset of names and email addresses of ClientPortal users were intercepted.
      • We determined that this information alone would not be considered sensitive, but we have nevertheless informed those people affected.
    5. The names of accounts in ClientPortal were intercepted.
      • This is a list of the names of organizations that we have exchanged files with in the past. This includes organizations such as customers, partners and suppliers.
      • After review, we determined that the names alone would not be considered sensitive.
  • Email: we know that the attacker intercepted Fox-IT email for a maximum of 10 minutes, and that during those 10 minutes, emails destined for Fox-IT were redirected to an external email provider. Since email distribution is decentralized on the internet, we have no way of determining which emails were intercepted by the attacker during that time.

The start of the incident response process

We have determined that the attacker successfully logged in to the DNS control panel of our third party domain registrar provider using valid credentials. This raises two key questions:

  • How were valid credentials obtained?
  • Why was access to the domain registrar possible with single factor rather than multi factor authentication?

On the question of how the credentials were obtained we have conducted extensive internal investigations alongside those conducted by the police investigating the incident. We interviewed people that had access to the vault, carried out extensive forensic investigation of all the systems that the password could been used on, and performed additional network forensics. We currently have no evidence that the password was stolen from any of our own internal systems. Right now, based on our own and the police investigation, we have strong evidence that supports our hypothesis that the adversary gained access to our credentials through the compromise of a third party provider. Investigations are ongoing.

A factor which possibly helped the attacker was that the password had not been changed since 2013. While our password is considered strong and can withstand brute force attacks, it was not changed because it was hardly ever used: DNS settings in general change very rarely. Nevertheless, this was something we could clearly have improved in our process.

The infrequency of our engagement with our domain registrar is also behind the answer to the second question, as to how the attacker was able to gain access to the DNS records solely using a username/password combination. Two factor authentication (2FA) – whereby the initial attempt to log-on can only be completed once a code sent to an authorized device is entered as second factor authentication – should be standard practice here. We chose our domain name registrar provider 18 years ago when 2FA was neither a consideration nor a possibility. We were surprised to find that the registrar still does not support 2FA. It is always worth asking: does your DNS registrar support 2FA? The answer may surprise you.

Reasonably quick detection but room for improvement

We hold our hands up to a number of errors on prevention, but we did decidedly better in the areas of detection and response. Once the attack was ongoing, we detected it reasonably quickly: within a few hours compared to the typical industry average of weeks before an attack is detected.

Our Security Operations Center (SOC) had noticed that a number of scans for weaknesses on our infrastructure were made in the days leading up to the attack. These were treated as regular “background noise on the internet” and not followed up on. While paying attention to those scans would probably not have helped us predict the following attack, it would certainly have raised our attention and we have now established mechanisms to improve early warning of suspicious security probing of this nature.

Effective response, containment and scope determination

In general, once an incident is detected, the most important goal becomes to limit the incident and determine the impact of the attack. Once we knew about the incident, we acted quickly and we were able to limit the impact of the incident quite effectively and in a timely manner.

The most important action that we took in order to limit the impact of the attack was to disable 2FA, in lieu of disabling login functionality altogether. We did this specifically to prevent people from successfully logging in but so as not to alert the attacker to the fact that we knew of the attack. This allowed us to better understand the modus operandi and scope of the attack before taking specific actions to mitigate it, an approach which is standard operating procedure for our CERT team. From that moment on, nobody could log in, effectively preventing traffic to our ClientPortal from being intercepted. Note that this did not directly stop the attack, but it stopped its effectiveness.

The use of full packet capture and CTMp network sensors was crucial in determining the scope of the attack. We could, within a few hours of finding out about the attack, determine exactly who was affected and what the scope of the attacker was. This helped us to understand the incident with confidence and to quickly notify those directly affected and the Dutch Data Protection Authority.

Lessons learned and recommendations

Looking back on this incident, we learned the following lessons and have the following recommendations:

  • Choose a DNS provider that doesn’t allow changes through a control panel but requires a more manual process, considering that name servers are very stable and hardly every change. If you do require more frequent changes, use 2FA.
  • Ensure that all system access passwords are reviewed regularly and changed, even those which are used rarely.
  • Deploy certificate transparency monitoring in order to detect, track and respond to fraudulent certificates.
  • Deploy full packet capture capabilities with good retention in crucial points of your infrastructure, such as the DMZ and border gateways.
  • Always inform Law Enforcement at an early stage, so that they can help you with your investigations, as we did in our case.
  • Make it a management decision to first understand an attack before taking specific actions to mitigate it. This may include letting an attack continue for a short period of time. We consciously made that decision.

Looking back in conclusion

While we deeply regret the incident and the shortcomings on our part which contributed to it, we also acknowledge that a number of the measures we had in place enabled us to detect the attack, respond quickly and confidently and thereby limited the scale and length of the incident. And that’s why the twin mantras in security should always be followed:

  • layered security; and
  • prevention, detection and response.

At the time that ‘if’ becomes ‘when’, it is the combination of these that ultimately determines your overall resilience and cyber security stance.

In the Clouds – Enterprise Security Weekly #72

Jeff Schilling, CSO of Armor joins us for an interview to discuss Cloud based security and incident response! In the news, updates from LogRhythm, Optiv Security, Fortinet, RiskSense, and more on this episode of Enterprise Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

IDG Contributor Network: Who are you really inviting in?

Back in the olden days, you might have hidden a key under the door mat, in a flower pot, or hanging on an inconspicuous nail somewhere on your property. It not only meant you would never be locked out of your own home, but it was also a move for safety or convenience. Paramedics could open your door with directions if you were hurt inside your home, and neighbors who called you at work about a large package on your doorstep could help you out by moving it inside.

Over the years, technology has caught up with our home security. For years now, retailers have sold front door deadbolt locks that allow outsiders access to your property by punching in the physical buttons on the lock, releasing the mechanism and letting them open the door. That meant changing out the code every single time you shared it with someone though, just to ensure that they didn’t come back at a later date.

To read this article in full, please click here

Hack Naked News #153 – December 12, 2017

Paul reports on Google patches, vulnerability in two keyless entry locks, Mozilla security updates, and 1.4 billion plain-text leaked passwords found online! Jason Wood of Paladin Security joins us for the expert commentary, and more on this episode of Hack Naked News!


Full Show Notes:


Visit for all the latest episodes!

Criminals in a festive mood

This morning the Fox-IT Security Operations Center observed a large number of phishing e-mails that contained a link to a downloadable zip file. Anyone downloading and opening that zip file would infect themselves with banking malware, that would subsequently try to lure the victim into divulging their credit card information.

So far nothing new: e-mail as attack vector, distribution of the Zeus Panda banking trojan, targeting the same institutions.

Except that this time, it appears the criminals are preparing for the festive season. What stood out to us is the inclusion of a number of local retailers that are now targeted by this banking trojan. Some targeted websites which were extracted from the configuration are:

  • Coolblue
  • Otto
  • Amazon
  • De Volksbank (SNS, ASN & Regiobank)
  • ING
  • ABN Amro
  • Knab
  • Triodos

So now, when someone has infected themselves with this malware by opening the malicious zip file, not only will the malware ask for their credit card details when they visit their bank’s website, but also when they visit an online retailer for (Christmas) shopping.

Read on for recommendations, notable observations, stats and screenshots and technical details including indicators of compromise.

The usual recommendations for end users apply: be alert for criminals attacking you by sending legitimate looking e-mails with links and attachments. And be alert for websites behaving differently and asking for credit card details or other personal data where they normally don’t. If you suspect an infection, you may check out a website from a different device to see if it behaves the same. If it doesn’t, you may be infected.

The e-mail itself is nothing out of the ordinary. It appears to be targeting the Netherlands and Germany, using Dutch text and faking the Dutch DHL Group. This is what it looks like:

Beste heer/mevrouw,
UW ZENDING IS ONDERWEG ,Informatie Over Uw Zending is in dokument.

Controleer hieronder uw zending- en contactgegevens. Klik op om te bevestigen.
Bedankt dat u heeft gekozen voor On Demand Delivery.
DHL Express – Excellence. Simply delivered.
Nederlandse Post DHL Group

For organisations, the recommendations are also familiar: isolate any infected systems prior to cleaning them, change any password that was used after infection and consider client certificates on that system compromised. You may refer to the indicators of compromise later on in this post.

Additional interesting observations
The malware that is being distributed is called Zeus Panda, which we’ve followed for almost two years now. This is a variant of the Zeus family of malware that Fox-IT has observed since around 2006, for the purpose of protecting its own customers. The name Zeus Panda comes from the web panel used by the malware operators.

At the time of writing, the two malicious zip file referred in the emails received a little over 48 thousand clicks, mostly in the Netherlands, but also in other parts of Western Europe and some in North America. Out of those 48 thousand clicks, only 11 thousand came from a Window system, which is the only platform that the malware runs on. The other 37 thousands people were safe! A clear example and proof of the shotgun approach that criminals still successfully use.

Also interesting is the clunky nature of the injects. As shown in the screenshots below, the code that the criminals inject into the website on the infected system looks, well, unfinished.

Full statistics
The link in the email is a Google Shortened URL, which downloads the zip-file from

By default Google shortened URL’s keeps track of the following statistics:
– Amount of clicks
– Used Browsers
– Referrers
– Countries
– Platforms

Requesting the statistics of the shortened URL results in the following statistics for:


Screenshot of the inject asking for credit card details
From an infected system, Zeus Panda will inject extra code into a website. Once the code is injected into one of the targeted web pages, an extra form is added for creditcard information. For example, Coolblue’s webshop page would look like this, clunky and unfinished. Please note that Coolblue has no control over the fact that criminals attempt to inject code into their website from infected machines.


Zeus Panda Banker web inject

EDIT: the total click count for both domains has increased to a total of 66 thousand, even though both ZIP-files are not available anymore.

Indicators of Compromise
hxxp:// (compromised website)
hxxp:// (compromised website)

hxxps:// (SSL connection)

—External panel for injects—

MD5: aefc0fe15836165291cb66eac5ffd177
SHA256: 588e31ac96bd6318f787602e87f86b75d4b5537679e11ba5a509589148033275

contactgegevens 12_2017_10_00_.js
MD5: deb9a0aa69270a0b263b80ed13880b24
SHA256: eb65b1d5f5b3ccc263a4984275c084b63b0a262a87d55887d6a4d744a75e4112

MD5: 4ac38a4efa276f8d64c1ed39a53e7ab8
SHA256: e556273db50d4588d7e4b5183d06d39b0ebedbb094fc2a39b59416212c829324

Making a simple network traffic graph with tshark and afterglow

Outputting a pcap file for CSV format for using afterglow. pl and neato (Graphviz) to create a graph
To make a simple source and destination graph..
First make the capture file using tcpdump
tcpdump -nn -i -q
Then use tshark to extract the source and destination IP address and output to a comma separated file
tshark -T fields -nn -r capture.pcap -E separator=, -e ip.src -e ip.dst > output.txt
Sort and remove duplicates
cat output.txt | sort | uniq > output.csv
or just sort to see all connections
cat output.txt | sort > output.csv
Edit file to remove any lines with incorrect data (like just a comma)
Process the file through afterglow to format in dot graph format that Graphviz can use
cat output.csv | afterglow/ -t >
Create your graph in .png format
cat | neato -Tpng > output.png

Weekly Cyber Risk Roundup: Bitcoin Attacks Dominate Headlines, New Phishing Warnings

Several cryptocurrency exchanges were among the week’s top trending cybercrime targets due to a variety of different currency thefts, data breaches, and warnings from researchers.


The most impactful incident occurred at the bitcoin mining platform and exchange NiceHash, which said on Wednesday that its payment system was compromised and the bitcoin in its wallet was stolen. NiceHash said it is “working to verify the precise number of BTC taken”; however, news outlets reported that a wallet linked to the attack obtained around 4,736 bitcoin, which is valued at more than $72 million based on Saturday’s price. The company has not released many details about the attack other than that it began after an employee’s computer was compromised.

In addition, researchers warned this week that the increased valuation of bitcoin has led to it becoming one of the top 10 most targeted industries for DDoS attacks. On Monday, Bitfinex said that its services were disrupted by a DDoS attack. On Thursday, Coinbase warned that the explosion of interest in digital currencies was creating “extreme volatility and stress” on its systems and warned its users to invest responsibly as any future downtime could impact their ability to trade.

News outlets also reported that some Bittrex customers who go through the company’s manual verification process but are rejected have received customer support emails that contain the passports details and photographs of other users, although Bittrex has not confirmed the reports.

Finally, the SEC announced that it obtained an emergency asset freeze to halt the Initial Coin Offering PlexCorps after it raised up to $15 million from thousands of investors by falsely promising a 13-fold profit in less than a month’s time.


Other trending cybercrime events from the week include:

  • TIO Networks announces breach: PayPal announced a breach at TIO Networks, a payment processor it acquired in July, that affects approximately 1.6 million customers. City Utilities (CU) and Duke Energy have since notified customers that their personal information was compromised due to the breach, as TIO was the provider of the operating system for CU’s payment kiosks and mobile payment app, in addition to being used to process Duke Energy’s in-person payments.
  • Payment card breaches: The Image Group is notifying customers of a temporary vulnerability on its eCommerce platform, Payflow Pro, that made some payment card numbers susceptible to interception while in transit to PayPal. JAM Paper & Envelope is notifying customers of a payment card card breach affecting its website due to unauthorized access by a third party. A payment card breach involving the Royal National Institute for the Blind’s web store affects as many as 817 customers, and around 55 individuals have already reported fraudulent activity as a result of the incident.
  • Extortion attacks: The Alameda County Library is notifying its users that their personal information may have been compromised after it received an extortion email that claimed hackers had gained access to the library’s entire database of users and may sell that information if they weren’t paid a five bitcoin ransom. The Mecklenburg County government in North Carolina said that its computer systems were infected with ransomware that is demanding $23,000 for the encryption key. Mad River Township Fire and EMS Department in Ohio said that years of data related to residents who used EMS or fire services was lost due to a ransomware infection. The fertility clinic CCRM Minneapolis said that nearly 3,300 patients may have had their information compromised due to a ransomware attack.
  • Other notable incidents: The Center for Health Care Services in San Antonio is notifying 28,434 patients that their personal information was stolen by a former employee. The County of Humboldt is notifying current and former employees that the Humboldt County Sheriff’s Office recovered payroll documents from the county. Pulmonary Specialists of Louisville is notifying patients their information may have been compromised due to possible unauthorized access. Virtual keyboard developer Ai.Type, bike sharing company oBike, Real Time Health Quotes, and Stanford University all had data breaches due to accidental data exposure. Baptist Health Louisville, Sinai Health System, and The Henry Ford Health System notified patients of employee email account breaches.
  • Law enforcement actions: Authorities reportedly shut down Leakbase, a service that sold access to more than two billion credentials collected from old data breaches. The Justice Department announced a software developer at the National Security Agency’s Tailored Access Operations has pleaded guilty to removing classified NSA data and later having that data stolen from his personal computer by Russian state-sponsored actors. A Michigan man pleaded guilty to gaining access to the Washtenaw County computer network and altering the electronic records of at least one inmate in an attempt to get the inmate released early. A Missouri man has been sentenced to six years in prison for hacking his former employer, American Crane & Tractor Parts, in order to steal trade secrets.

SurfWatch Labs collected data on many different companies tied to cybercrime over the past week. Some of those “newly seen” targets, meaning they either appeared in SurfWatch Labs’ data for the first time or else reappeared after being absent for several weeks, are shown in the chart below.


Cyber Risk Trends From the Past Week

2017-12-8_RiskScoresPhishing concerns were highlighted once again this past week due to a newly announced vulnerability that allows malicious actors to spoof emails, as well as warnings that phishers are making efforts to appear more legitimate.

A researcher has discovered a collection of bugs in email clients, dubbed “Mailsploit,” that circumvents spoofing protection mechanisms and, in some cases, allows code injection attacks. The vulnerabilities were found in dozens of applications, including Apple Mail, Mozilla Thunderbird, Microsoft Outlook 2016, Yahoo! Mail, ProtonMail, and others.

The bug has been fixed in 10 products and triaged for 8 additional products, the researcher said. In addition, Mozilla and Opera said they won’t fix the bug as they consider it to be a server-side problem; however, Thunderbird developer Jörg Knobloch told Wired that a patch would be made available. DMARC spoofing protection is not attacked directly using Mailsploit,  the researcher said, but rather bypassed by taking advantage of how the clients display the email sender name.

In addition, researchers said that nearly a quarter of all phishing websites are now hosted on HTTPS domains, up from three percent a year ago. The increase is due to both an increased number of HTTPS websites that can be compromised and used to host malicious content, as well as phishers registering HTTPS domains themselves due to their belief that the “HTTPS” designation makes a phishing site seem more legitimate to potential victims. An informal poll conducted by PhishLabs found that more than 80% of the respondents incorrectly believed the green padlock associated with HTTPS websites indicated that a website was either legitimate or safe — when in reality it only means that the connection is encrypted.

Individuals and organizations should be aware that malicious actors continue to leverage exploits like Mailsploit along with more secure-looking websites in order to dupe potential victims via phishing attacks with the goal of installing malware, gaining access to networks, or stealing sensitive data.

Channeling Back – Startup Security Weekly #65

Todd O'Boyle of StrongArm joins us for an interview! In our article discussion, we discuss behaviors that can drive cultural change, the power of office back-channeling, and the five traits of successful teams at Google! In the news, we have updates from InterVision, Prevoty, Okta, and Riskonnect, and more on this episode of Startup Security Weekly

Full Show Notes:

Visit for all the latest episodes!


Paul’s Security Weekly #539 – Dental Security Weekly

Lisa O'Connor of Accenture Labs joins us for an interview to discuss threat intelligence, advanced cyber hunting, active defense, and security of the Industrial Internet of things! Eyal Neemany of Javelin Networks joins us for the tech segment to discuss bypassing Two-Factor Authentication! Paul and Larry talk about Uber, vulnerable banking apps, and bluetooth on the news, on this weeks episode of Paul's Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

→Follow us on Twitter:

→Like us on Facebook:

Detection and recovery of NSA’s covered up tracks

Part of the NSA cyber weapon framework DanderSpritz is eventlogedit, a piece of software capable of removing individual lines from Windows Event Log files. Now that this tool is leaked and public, any criminal willing to remove its traces on a hacked computer can use it. Fox-IT has looked at the software and found a unique way to detect the use of it and to recover the removed event log entries.


A group known as The Shadow Brokers published a collection of software, which allegedly was part of the cyber weapon arsenal of the NSA. Part of the published software was the exploitation framework FuzzBunch and post-exploitation framework DanderSpritz. DanderSpritz is a full-blown command and control server, or listening post in NSA terms. It can be used to stealthy perform various actions on hacked computers, like finding and exfiltrating data or move laterally through the target network. Its GUI is built on Java and contains plugins written in Python. The plugins contain functionality in the framework to perform specific actions on the target machine. One specific plugin in DanderSpritz caught the eye of the Forensics & Incident Response team at Fox-IT: eventlogedit.

DanderSpritz with eventlogedit in action

Figure 1: DanderSpritz with eventlogedit in action


Normally, the content of Windows Event Log files is useful for system administrators troubleshooting system performance, security teams monitoring for incidents, and forensic and incident response teams investigating a breach or fraud case. A single event record can alert the security team or be the smoking gun during an investigation. Various other artefacts found on the target system usually corroborate findings in Windows Event Log files during an investigation, but a missing event record could reduce the chances of detection of an attack, or impede investigation.

Fox-IT has encountered event log editing by attackers before, but eventlogedit appeared to be more sophisticated. Investigative methods able to spot other methods of event log manipulation were not able to show indicators of edited log files after the use of eventlogedit. Using eventlogedit, an attacker is able to remove individual event log entries from the Security, Application and System log on a target Windows system. After forensic analysis of systems where eventlogedit was used, the Forensics & Incident Response team of Fox-IT was able to create a Python script to detect the use of eventlogedit and fully recover the removed event log entries by the attacker.

Analysing recovered event records, deleted by an attacker, gives great insight into what an attacker wanted to hide and ultimately wanted to achieve. This provides security and response teams with more prevention and detection possibilities, and investigative leads during an investigation.

Before (back) and after (front) eventlogedit

Figure 2: Before (back) and after (front) eventlogedit

eventlogedit in use

Starting with Windows Vista, Windows Event Log files are stored in the Windows XML Eventlog format. The files on the disk have the file extension .evtx and are stored in the folder \Windows\System32\winevt\Logs\ on the system disk, by default. The file structure consists of a file header followed by one or more chunks. A chunk itself starts with a header followed by one or more individual event records. The event record starts with a signature, followed by record size, record number, timestamp, the actual event message, and the record size once again. The event message is encoded in a proprietary binary XML format, binXml. BinXml is a token representation of text XML.

Fox-IT discovered that when eventlogedit is used, the to-be-removed event record itself isn’t edited or removed at all: the record is only unreferenced. This is achieved by manipulation of the record header of the preceding record. Eventlogedit adds the size of the to-be-removed-record to the size of the previous record, thereby merging the two records. The removed record including its record header is now simply seen as excess data of the preceding record. In Figure 3 this is illustrated. You might think that an event viewer would show this excess or garbage data, but no. Apparently, all tested viewers parse the record binXml message data until the first end-tag and then move on to the next record. Tested viewers include Windows Event Viewer as well as various other forensic event log viewers and parsers. None of them was able to show a removed record.

Untouched event records (left) and deleted event record (right)

Figure 3: Untouched event records (left) and deleted event record (right). Note: not all field are displayed here.

Merely changing the record size would not be enough to prevent detection: various fields in the file and chunk header need to be changed. Eventlogedit makes sure that all following event records numbers are renumbered and that checksums are recalculated in both the file and chunk header. Doing so, it makes sure that obvious anomalies like missing record numbers or checksum errors are prevented and will not raise an alarm at the system user, or the security department.

Organizations which send event log records on the fly to a central log server (e.g. a SIEM), should be able to see the removed record on their server. However, an advanced attacker will most likely compromise the log server before continuing the operation on the target computer.

Recovering removed records

As eventlogedit leaves the removed record and record header in its original state, their content can be recovered. This allows the full recovery of all the data that was originally in the record, including record number, event id, timestamps, and event message.

Fox-IT’s Forensics & Incident Response department has created a Python script that finds and exports any removed event log records from an event log file. This script also works in the scenario when consecutive event records have been removed, when the first record of the file is removed, or the first record of a chunk is removed. In Figure 4 an example is shown.

Recovering removed event records

Figure 4: Recovering removed event records

We have decided to open source the script. It can be found on our GitHub and works like this:

$ python -h
usage: [-h] -i INPUT_PATH [-o OUTPUT_PATH]
 [-e EXPORT_PATH] - Parse evtx files and detect the use of the danderspritz
module that deletes evtx entries

optional arguments:
 -h, --help show this help message and exit
 Path to evtx file
 Path to corrected evtx file
 Path to location to store exported xml records

The script requires the python-evtx library from Willi Ballenthin.

Additionally, we have created an easy to use standalone executable for Windows systems which can be found on our GitHub as well.


md5    c07f6a5b27e6db7b43a84c724a2f61be 
sha1   6d10d80cb8643d780d0f1fa84891a2447f34627c
sha256 6c0f3cd832871ba4eb0ac93e241811fd982f1804d8009d1e50af948858d75f6b



To detect if the NSA or someone else has used this to cover up his tracks using the eventlogedit tool on your systems, it is recommended to use the script on event log files from your Windows servers and computers. As the NSA very likely changed their tools after the leaks, it might be farfetched to detect their current operations with this script. But you might find traces of it in older event log files. It is recommended to run the script on archived event log files from back-ups or central log servers.

If you find traces of eventlogedit, and would like assistance in analysis and remediation for a possible breach, feel free to contact us. Our Forensics & Incident Response department during business hours or FoxCERT 24/7.

Wouter Jansen
Fox-IT Forensics & Incident Response


NCCIC is aware of a public report of an improper authentication vulnerability affecting WAGO PFC200, a Programmable Logic Controller (PLC) device. According to this report, the vulnerability is exploitable by sending a TCP payload on the bound port. This report was released after attempted coordination with WAGO. NCCIC has notified the affected vendor of the report and has asked the vendor to confirm the vulnerability and identify mitigations. NCCIC is issuing this alert to provide notice of the report and identify baseline mitigations for reducing risks to these and other cybersecurity attacks.

New Targeted Attack in the Middle East by APT34, a Suspected Iranian Threat Group, Using CVE-2017-11882 Exploit

Less than a week after Microsoft issued a patch for CVE-2017-11882 on Nov. 14, 2017, FireEye observed an attacker using an exploit for the Microsoft Office vulnerability to target a government organization in the Middle East. We assess this activity was carried out by a suspected Iranian cyber espionage threat group, whom we refer to as APT34, using a custom PowerShell backdoor to achieve its objectives.

We believe APT34 is involved in a long-term cyber espionage operation largely focused on reconnaissance efforts to benefit Iranian nation-state interests and has been operational since at least 2014. This threat group has conducted broad targeting across a variety of industries, including financial, government, energy, chemical, and telecommunications, and has largely focused its operations within the Middle East. We assess that APT34 works on behalf of the Iranian government based on infrastructure details that contain references to Iran, use of Iranian infrastructure, and targeting that aligns with nation-state interests.

APT34 uses a mix of public and non-public tools, often conducting spear phishing operations using compromised accounts, sometimes coupled with social engineering tactics. In May 2016, we published a blog detailing a spear phishing campaign targeting banks in the Middle East region that used macro-enabled attachments to distribute POWBAT malware. We now attribute that campaign to APT34. In July 2017, we observed APT34 targeting a Middle East organization using a PowerShell-based backdoor that we call POWRUNER and a downloader with domain generation algorithm functionality that we call BONDUPDATER, based on strings within the malware. The backdoor was delivered via a malicious .rtf file that exploited CVE-2017-0199.

In this latest campaign, APT34 leveraged the recent Microsoft Office vulnerability CVE-2017-11882 to deploy POWRUNER and BONDUPDATER.

The full report on APT34 is available to our MySIGHT customer community. APT34 loosely aligns with public reporting related to the group "OilRig". As individual organizations may track adversaries using varied data sets, it is possible that our classifications of activity may not wholly align.

CVE-2017-11882: Microsoft Office Stack Memory Corruption Vulnerability

CVE-2017-11882 affects several versions of Microsoft Office and, when exploited, allows a remote user to run arbitrary code in the context of the current user as a result of improperly handling objects in memory. The vulnerability was patched by Microsoft on Nov. 14, 2017. A full proof of concept (POC) was publicly released a week later by the reporter of the vulnerability.

The vulnerability exists in the old Equation Editor (EQNEDT32.EXE), a component of Microsoft Office that is used to insert and evaluate mathematical formulas. The Equation Editor is embedded in Office documents using object linking and embedding (OLE) technology. It is created as a separate process instead of child process of Office applications. If a crafted formula is passed to the Equation Editor, it does not check the data length properly while copying the data, which results in stack memory corruption. As the EQNEDT32.exe is compiled using an older compiler and does not support address space layout randomization (ASLR), a technique that guards against the exploitation of memory corruption vulnerabilities, the attacker can easily alter the flow of program execution.


APT34 sent a malicious .rtf file (MD5: a0e6933f4e0497269620f44a083b2ed4) as an attachment in a malicious spear phishing email sent to the victim organization. The malicious file exploits CVE-2017-11882, which corrupts the memory on the stack and then proceeds to push the malicious data to the stack. The malware then overwrites the function address with the address of an existing instruction from EQNEDT32.EXE. The overwritten instruction (displayed in Figure 1) is used to call the “WinExec” function from kernel32.dll, as depicted in the instruction at 00430c12, which calls the “WinExec” function.

Figure 1: Disassembly of overwritten function address

After exploitation, the ‘WinExec’ function is successfully called to create a child process, “mshta.exe”, in the context of current logged on user. The process “mshta.exe” downloads a malicious script from hxxp://mumbai-m[.]site/b.txt and executes it, as seen in Figure 2.

Figure 2: Attacker data copied to corrupt stack buffer

Execution Workflow

The malicious script goes through a series of steps to successfully execute and ultimately establish a connection to the command and control (C2) server. The full sequence of events starting with the exploit document is illustrated in Figure 3.

Figure 3: CVE-2017-11882 and POWRUNER attack sequence

  1. The malicious .rtf file exploits CVE-2017-11882.
  2. The malware overwrites the function address with an existing instruction from EQNEDT32.EXE.
  3. The malware creates a child process, “mshta.exe,” which downloads a file from: hxxp://mumbai-m[.]site/b.txt.
  4. b.txt contains a PowerShell command to download a dropper from: hxxp://dns-update[.]club/v.txt. The PowerShell command also renames the downloaded file from v.txt to v.vbs and executes the script.
  5. The v.vbs script drops four components (hUpdateCheckers.base, dUpdateCheckers.base, cUpdateCheckers.bat, and GoogleUpdateschecker.vbs) to the directory: C:\ProgramData\Windows\Microsoft\java\
  6. v.vbs uses CertUtil.exe, a legitimate Microsoft command-line program installed as part of Certificate Services, to decode the base64-encoded files hUpdateCheckers.base and dUpdateCheckers.base, and drop hUpdateCheckers.ps1 and dUpdateCheckers.ps1 to the staging directory.
  7. cUpdateCheckers.bat is launched and creates a scheduled task for GoogleUpdateschecker.vbs persistence.
  8. GoogleUpdateschecker.vbs is executed after sleeping for five seconds.
  9. cUpdateCheckers.bat and *.base are deleted from the staging directory.

Figure 4 contains an excerpt of the v.vbs script pertaining to the Execution Workflow section.

Figure 4: Execution Workflow Section of v.vbs

After successful execution of the steps mentioned in the Execution Workflow section, the Task Scheduler will launch GoogleUpdateschecker.vbs every minute, which in turn executes the dUpdateCheckers.ps1 and hUpdateCheckers.ps1 scripts. These PowerShell scripts are final stage payloads – they include a downloader with domain generation algorithm (DGA) functionality and the backdoor component, which connect to the C2 server to receive commands and perform additional malicious activities. 

hUpdateCheckers.ps1 (POWRUNER)

The backdoor component, POWRUNER, is a PowerShell script that sends and receives commands to and from the C2 server. POWRUNER is executed every minute by the Task Scheduler. Figure 5 contains an excerpt of the POWRUNER backdoor.

Figure 5: POWRUNER PowerShell script hUpdateCheckers.ps1

POWRUNER begins by sending a random GET request to the C2 server and waits for a response. The server will respond with either “not_now” or a random 11-digit number. If the response is a random number, POWRUNER will send another random GET request to the server and store the response in a string. POWRUNER will then check the last digit of the stored random number response, interpret the value as a command, and perform an action based on that command. The command values and the associated actions are described in Table 1.





Server response string contains batch commands

Execute batch commands and send results back to server


Server response string is a file path

Check for file path and upload (PUT) the file to server


Server response string is a file path

Check for file path and download (GET) the file

Table 1: POWRUNER commands

After successfully executing the command, POWRUNER sends the results back to the C2 server and stops execution.

The C2 server can also send a PowerShell command to capture and store a screenshot of a victim’s system. POWRUNER will send the captured screenshot image file to the C2 server if the “fileupload” command is issued. Figure 6 shows the PowerShell “Get-Screenshot” function sent by the C2 server.

Figure 6: Powershell Screenshot Functionality

dUpdateCheckers.ps1 (BONDUPDATER)

One of the recent advancements by APT34 is the use of DGA to generate subdomains. The BONDUPDATER script, which was named based on the hard-coded string “B007”, uses a custom DGA algorithm to generate subdomains for communication with the C2 server.

DGA Implementation

Figure 7 provides a breakdown of how an example domain (456341921300006B0C8B2CE9C9B007.mumbai-m[.]site) is generated using BONDUPDATER’s custom DGA.

Figure 7: Breakdown of subdomain created by BONDUPDATER

  1. This is a randomly generated number created using the following expression: $rnd = -join (Get-Random -InputObject (10..99) -Count (%{ Get-Random -InputObject (1..6)}));
  2. This value is either 0 or 1. It is initially set to 0. If the first resolved domain IP address starts with 24.125.X.X, then it is set to 1.
  3. Initially set to 000, then incremented by 3 after every DNS request
  4. First 12 characters of system UUID.
  5. “B007” hardcoded string.
  6. Hardcoded domain “mumbai-m[.]site”

BONDUPDATER will attempt to resolve the resulting DGA domain and will take the following actions based on the IP address resolution:

  1. Create a temporary file in %temp% location
    • The file created will have the last two octets of the resolved IP addresses as its filename.
  2. BONDUPDATER will evaluate the last character of the file name and perform the corresponding action found in Table 2.




File contains batch commands, it executes the batch commands


Rename the temporary file as .ps1 extension


Rename the temporary file as .vbs extension

Table 2: BONDUPDATER Actions

Figure 8 is a screenshot of BONDUPDATER’s DGA implementation.

Figure 8: Domain Generation Algorithm

Some examples of the generated subdomains observed at time of execution include:




Network Communication

Figure 9 shows example network communications between a POWRUNER backdoor client and server.

Figure 9: Example Network Communication

In the example, the POWRUNER client sends a random GET request to the C2 server and the C2 server sends the random number (99999999990) as a response. As the response is a random number that ends with ‘0’, POWRUNER sends another random GET request to receive  an additional command string. The C2 server sends back Base64 encoded response.

If the server had sent the string “not_now” as response, as shown in Figure 10, POWRUNER would have ceased any further requests and terminated its execution.

Figure 10: Example "not now" server response

Batch Commands

POWRUNER may also receive batch commands from the C2 server to collect host information from the system. This may include information about the currently logged in user, the hostname, network configuration data, active connections, process information, local and domain administrator accounts, an enumeration of user directories, and other data. An example batch command is provided in Figure 11.

Figure 11: Batch commands sent by POWRUNER C2 server


APT34 has used POWRUNER and BONDUPDATER to target Middle East organizations as early as July 2017. In July 2017, a FireEye Web MPS appliance detected and blocked a request to retrieve and install an APT34 POWRUNER / BONDUPDATER downloader file. During the same month, FireEye observed APT34 target a separate Middle East organization using a malicious .rtf file (MD5: 63D66D99E46FB93676A4F475A65566D8) that exploited CVE-2017-0199. This file issued a GET request to download a malicious file from:


As shown in Figure 12, the script within the dupatechecker.doc file attempts to download another file named dupatechecker.exe from the same server. The file also contains a comment by the malware author that appears to be an apparent taunt to security researchers.

Figure 12: Contents of dupdatechecker.doc script

The dupatechecker.exe file (MD5: C9F16F0BE8C77F0170B9B6CE876ED7FB) drops both BONDUPDATER and POWRUNER. These files connect to proxychecker[.]pro for C2.

Outlook and Implications

Recent activity by APT34 demonstrates that they are capable group with potential access to their own development resources. During the past few months, APT34 has been able to quickly incorporate exploits for at least two publicly vulnerabilities (CVE-2017-0199 and CVE-2017-11882) to target organizations in the Middle East. We assess that APT34’s efforts to continuously update their malware, including the incorporation of DGA for C2, demonstrate the group’s commitment to pursing strategies to deter detection. We expect APT34 will continue to evolve their malware and tactics as they continue to pursue access to entities in the Middle East region.


Filename / Domain / IP Address

MD5 Hash or Description

CVE-2017-11882 exploit document





















Malware Staging Server

CVE-2017-0199 exploit document


Malware Staging Server







Has resolved mumbai-m[.]site & hpserver[.]online

Has resolved mumbai-m[.]site and dns-update[.]club

Has resolved dns-update[.]club

Has resolved dns-update[.]club

Has resolved ns2.dns-update[.]club & hpserver[.]online & anyportals[.]com




























In Which You Get a Chance to Save Democracy

Let’s start with the end: you can do something to change the broken political landscape in the United States, but you have to act quickly. Here’s a link to donate directly to outsider candidates I support who aren’t getting the funds they need. They are dedicated to working for their constituents’ healthcare, jobs, and community, but their districts are low income and have been ignored by national Democratic leadership. Any amount helps, no matter how small, but if you’re not a US citizen or permanent resident and can’t donate, at least you can help get the word out.

A few decades ago, I started became concerned about the national political landscape. Bush’s war on terror and the PATRIOT act were nightmares for freedom, and then Obama increased surveillance and drone strikes. At the same time, corporate lobbyists and PACs had grown to overrun the electoral process with their outsized influence.

The US is a rich country in funds and resources, but also in values. The Declaration of Independence puts it right up front: people have inherent rights that can’t be legislated away, and the government is there to secure those rights, drawing its power from the people. We don’t always live up to these values, but change has come upon us time and again with simple questions like, “am I not a man and a brother?

We are now at a critical point. Ignore the distracting presidency — Republicans are openly backing corporations & the wealthy by driving up the deficit and dismantling the thin safety net we have. Establishment Democrats are disorganized and out of touch with their roots, siding with financial interests instead of the poor and middle class. It’s time for a change.

Given that there isn’t a strong third party, the best bet is to renovate the Democrats from the inside. Too often, they have run weak candidates in districts that were too small or rural for them to care about, or even let the race go unopposed.

This has been a mistake. There is a huge vacuum for truly populist, outsider candidates. For 2018, the Democratic establishment appears to be cruising on anti-Trump sentiment, hoping enough voters are energized by his antics to turn against their local Republicans. Their tired playbook of dumping tons of outside money into business-friendly candidates to annoy residents with nonstop TV ads late in the campaign is another mistake.

The good news is that first-time Democratic candidates are running that support common sense policies like access to healthcare, investing in infrastructure, and education. And, they’re focused on the basics: build a ground campaign that talks to voters and recruits volunteers to get out the vote. The community they build will outlast this one election. But since they’re running in districts that have been ignored by the Democratic organization, they are lacking basic funds.

More good news: we’re not talking a lot of money. Your $10 or $100 donation makes a huge difference when $2,000/month hires a staff member. I know many of you are engineers & entrepreneurs that can give even more.

If these outsider candidates raise enough money before the primaries next year, it gets very interesting. The national Democratic party will notice the schoolteacher that just wiped the floor with their perennial, bland contender, outraising them with individual donations. Once they’re in the spotlight, these candidates will attract much more funding going into the main election and win their races.

Time is running out for 2017 to get these candidates off to a good start, so please consider giving an amount that hurts a bit, because it will be too late if we wait for the Democratic leadership to figure it out on their own.

Hack Naked News #152 – December 5, 2017

Paul reports on a flaw found in Dirty COW patch, Apache Software security updates, more hacks in 2018, and a MailSploit e-mail spoofing flaw! Jason Wood joins us to give expert commentary on a Federal Data Breach Legislation, and more on this episode of Hack Naked News!Full Show Notes:

Visit for all the latest episodes!

Startup Security Weekly #64 – Legal in Some States

Zach Schlumpf of IOActive joins us. In our article discussion, we talk about winning arguments, turning insight into execution, and avoiding the "Yes" dilemma. In the news, we have updates from Bitdefender, McAfee, Barracuda Networks, Pwnie Express, ReversingLabs, and more on this episode of Startup Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

Some random thoughts on Damian Green and those porn allegations

If you live in the UK then you might have noticed the somewhat bizarre furore over Damian Green MP and his alleged viewing of pornography on house his Parliament computer. Now, I don't know for certain if he did or didn't, but to put it in context his private email address also allegedly turned up in the Ashley Madison leak and on top of that there are sexual harassment allegations too. But

On "Advanced" Network Security Monitoring

My TaoSecurity News page says I taught 41 classes lasting a day or more, from 2002 to 2014. All of these involved some aspect of network security monitoring (NSM). Many times students would ask me when I would create the "advanced" version of the class, usually in the course feedback. I could never answer them, so I decided to do so in this blog post.

The short answer is this: at some point, advanced NSM is no longer NSM. If you consider my collection - analysis - escalation - response model, NSM extensions from any of those phases quickly have little or nothing to do with the network.

Here are a few questions I have received concerned "advanced NSM," paired with the answers I could have provided.

Q: "I used NSM to extract a binary from network traffic. What do I do with this binary?"

A: "Learn about reverse engineering and binary analysis."


Q: "I used NSM to extra Javascript from a malicious Web page. What do I do with this Javascript?"

A: "Learn about Javascript de-obfuscation and programming."


Q: "I used NSM to capture an exchange between a Windows client and a server. What does it mean?"

A: "Learn about Server Message Block (SMB) or Common Internet File System (CIFS)."


Q: "I used NSM to capture cryptographic material exchanged between a client and a server. How do I understand it?"

A: "Learn about cryptography."


Q: "I used NSM to grab shell code passed with an exploit against an Internet-exposed service. How do I tell what it does?"

A: "Learn about programming in assembly."


Q: "I want to design custom hardware for packet capture. How do I do that?"

A: "Learn about programming ASICs (application specific integrated circuits)."

I realized that I had the components of all of this "advanced NSM" material in my library. I had books on reverse engineering and binary analysis, Javascript, SMB/CIFS, cryptography, assembly programming, ASICs, etc.

The point is that eventually the NSM road takes you to other aspects of the cyber security landscape.

Are there *any* advanced area for NSM? One could argue that protocol analysis, as one finds in tools like Bro, Suricata, Snort, Wireshark, and so on constitute advanced NSM. However, you could just as easily argue that protocol analysis becomes more about understanding the programming and standards behind each of the protocols.

In brief, to learn advanced NSM, expand beyond NSM.

Paul’s Security Weekly #538 – Enjoy the Taste

Allison Miller joins us for an interview, Mick Douglas of the SANS Institute shows us how to feed common and default logs into ELK stacks, and we report on the latest security news on this episode of Paul's Security Weekly!

Full Show Notes:

Visit for all the latest episodes!

→Follow us on Twitter:

→Like us on Facebook: