Monthly Archives: June 2018

WHAT is the ONE Essential Cyber Security Capability WITHOUT which NOT a single Active Directory object or domain can be adequately secured?


Hello again. Today onwards, as I had promised, it is finally TIME for us to help SAFEGUARD Microsoft's Global Ecosystem.

Before I share how we uniquely do so, or answer this paramount question, or ask more such ones, I thought I'd ask likely the most important question that today DIRECTLY impacts the foundational cyber security of 1000s of organizations worldwide.

Here It Is -
What Is the 1 Essential Cyber Security Capability Without Which NOT a single Active Directory object, domain, forest or deployment can be adequately secured?

A Hint

I'll give you a hint. It controls exactly who is denied and who is granted access to literally everything within Active Directory.

In fact, it comes into play every time anyone accesses anything in any Active Directory domain in any organization worldwide.

Make No Mistake

Make no mistake about it - one simply CANNOT adequately protect anything in any Active Directory WITHOUT possessing this ONE capability, and thus one simply cannot protect the very foundation of an organization's cyber security without possessing this ONE paramount cyber security capability. It unequivocally is as remarkably simple, elemental and fundamental as this.

Only 2 Kinds of Organizations

Thus, today there are only two kinds of organizations worldwide - those that possess this paramount cyber security capability, and those that don't. Those that don't possess this essential capability do not have the means to, and thus cannot adequately protect, their foundational Active Directory deployments, and thus by logic are provably and demonstrably insecure.

If you know the answer, feel free to leave a comment below.
I'll answer this question right here, likely on July 04, 2018.


Why Do SOCs Look Like This?

When you hear the word "SOC," or the phrase "security operations center," what image comes to mind? Do you think of analyst sitting at desks, all facing forward, towards giant screens? Why is this?

The following image is from the outstanding movie Apollo 13, a docudrama about the challenged 1970 mission to the moon.

It's a screen capture from the go for launch sequence. It shows mission control in Houston, Texas. If you'd like to see video of the actual center from 1970, check out This Is Mission Control.

Mission control looks remarkably like a SOC, doesn't it? When builders of computer security operations centers imagined what their "mission control" rooms would look like, perhaps they had Houston in mind?

Or perhaps they thought of the 1983 movie War Games?

Reality was way more boring however:

I visited NORAD under Cheyenne Mountain in 1989, I believe, when visiting the Air Force Academy as a high school senior. I can confirm it did not look like the movie depiction!

Let's return to mission control. Look at the resources available to personnel manning the mission control room. The big screens depict two main forms of data: telemetry and video of the rocket. What about the individual screens, where people sit? They are largely customized. Each station presents data or buttons specific to the role of the person sitting there. Listen to Ed Harris' character calling out the stations: booster, retro, vital, etc. For example:

This is one of the key differences between mission control and any modern computerized operations center. In the 1960s and 1970s, workstations (literally, places where people worked) had to be customized. They lacked the technology to have generic workstations where customization was done via screen, keyboard, and mouse. They also lacked the ability to display video on demand, and relied on large television screens. Personnel with specific functions sat at specific locations, because that was literally the only way they could perform their jobs.

With the advent of modern computing, every workstation is instantly customizable. There is no need to specialize. Anyone can sit anywhere, assuming computers allow one's workspace to follow their logon. In fact, modern computing allows a user to sit in spaces outside of their office. A modern mission control could be distributed.

With that in mind, what does the current version of mission control look like? Here is a picture of the modern Johnson Space Center's mission control room.

It looks similar to the 1960s-1970s version, except it's dominated by screens, keyboards, and mice.

What strikes me about every image of a "SOC" that I've ever seen is that no one is looking at the big screens. They are almost always deployed for an audience. No one in an operational role looks at them.

There are exceptions. Check out the Arizona Department of Transportation operations center.

Their "big screen" is a composite of 24 smaller screens showing traffic and roadways. No one is looking at the screen, but that sort of display is perfect for the human eye.

It's a variant of Edward Tufte's "small multiple" idea. There is no text. The eye can discern if there is a lot of traffic, or little traffic, or an accident pretty easily. It's likely more for the benefit of an audience, but it works decently well.

Compare those screens to what one is likely to encounter in a cyber SOC. In addition to a "pew pew" map and a "spinning globe of doom," it will likely look like this, from R3 Cybersecurity:

The big screens are a waste of time. No one is standing near them. No one sitting at their workstations can read what the screens show. They are purely for an audience, who can't discern what they show either.

The bottom line for this post is that if you're going to build a "SOC," don't build it based on what you've seen in the movies, or in other industries, or what a consultancy recommends. Spend some time determining your SOC's purpose, and let the workflow drive the physical setting. You may determine you don't even need a "SOC," either physically or logically, based on maturing understandings of a SOC's mission. That's a topic for a future post!

Attacking Machine Learning Detectors: the state of the art review

Machine learning (ML) is a great approach to detect Malware. It is widely used among technical community and scientific community with two different perspectives: Performance V.S Robustness. The technical community tries to improve ML performances in order to increase the usability on large scale while scientific community is focusing on robustness by meaning how easy it would be to attack a ML detector engine. Today I'd like to focus our attention a little bit on the second perspective pointing up how to attack ML detector engines.

We might start by classifying machine learning attacks in three main sets:

  1. Direct Gradient-Based Attack. The attacker needs to know the ML Model. The attacker needs to know model structure and model weights in order to make direct queries to the Machine Learning Model and figure out what is the best way to evade the it.
  2. Score Model Attack. This attack set is based on the score systems. The attacker does not know the Machine Learning Model nor its own weights but he has direct access to the detector engine so that he can probe the machine learning model. The model will return a score and based on such a score, the attacker would be able to guess how to minimise it by forcing specific and crafted inputs.
  3. Binary Black Box Attack.  The attacker has no idea about the Machine Learning Model and the applied Weights, he has also no idea about the scoring system but he have unlimited access to probe the Machine Learning Model. 
Direct Gradient-Based Attack

Direct gradient based attack could be implemented in at least two ways. A first and most used way, is to apply small changes to the original sample in order to reduce the given score. The changes must be limited to a specific domain, for example: valid Windows PE file or  valid PDF files, and so forth. The changes must be little and they should be generated in order to minimise a scoring function derived by weights (which are know fro Direct Gradient-Based Attack). A second way is to connect the targeted model (the mode which is under attack) to a generator model in a generative adversarial network (GAN). Unlike the previous set, the  GAN generator learns how to generate a complete new sample derived by a given seed able to minimise the scoring function. 

I.Goodfellow et Al. in their work "Explaining and Harnessing Adversial Examples" (here) showed how little changes targeted to minimise the resulting weights on a given sample X would be effective in ML evasion. Another great work is written by K.Grosse et Al. titles: "Adversial Perturbations against deep neural networks for malware classification" (here). The authors attacked a deep learning Android malware model, based on DREBIN Android Malware data set, by apply a imperceptible perturbation on the feature vector. They had very interesting results getting from 50% to 84% of evasion rate.   I.Goodfellow et Al. in their work titled "Generative Adversial Nets" (here) developed a GAN able to iterate a series of adversarial rounds to generate samples that were classified as "ham" from the targeted model but that really were not. The following image shows a generative adversarial nets are trained by simultaneously updating the discriminative distribution (D, blue, dashed line) so that it discriminates between samples from the data generating distribution (black,dotted line) px from those of the generative distribution pg (G) (green, solid line).

Image from: "Generative Adversial Nets"

Score Model Attack

The attacker posture on that attack set is considered as "myope". The attacker does not know exactly how the ML model works and he has no idea about how the weights changes inside the ML algorithm but he has the chances to test his sample and getting back a score so that he is able to measure the effect of the input perturbation.

W. Xu, Y. Qi and D. Evans in their work titled: "Automatically evading classifiers" (here) implemented a "fitness function" which gives a fitness score of each generated variant. A variant with a positive fitness score is evasive. The fitness score holds the logic behind the targeted model classified as benign the current sample but retains a malicious behaviour. Once the sample gets high fitness score it is used a seed into a more general genetic algorithm which starts to manipulate the seed in order to make different species. To assure that those mutations preserve the desired malicious behaviour according to the original seed the authors used an oracle. In that case they used cuckoo sandbox.

Image from: "Automatically evading classifiers"

After one week of execution the genetic algorithm found nearly more then 15k evasive variants from 500 circa malicious seeds, getting the 100% of evasion rate on PDFrate classifier.

Binary black-box attacks

Binary black-box attacks are the most general one since attacker does not know anything about the used model and the anti malware engine just says: True or False (it's a Malware or it is not a Malware). In 2017 W.Hu and Y.Tan made a great work described in "Generating Adversarial Malware Examples for Malware Classification" (here). The authors developed MalGAN an Adversial Malware generator able to generate valid PE Malware to evade static black-box PE malware engine. The idea behind MalGAN is simple. First the attacker maps the Black-Box outputs by providing specific and Known Samples (Malware and Good PE). After the mapping phase the attacker builds a Model that behaves as the black-box Model. It is a simple Model trained to behave as the targeted one. Then the built Model is used as target model in a gradient computation GAN to produce evasive Malware. The authors reported 100% efficacy in bypassing the target Model. H. S. Anderson et Al. in "Evading Machine Learning Malware Detection" (here) adopted a Reinforced Learning Approach. The following image shows the Markov decision process formulation of the malware evasion reinforcement learning problem.

Image from: Evading Machine Learning Malware Detection

The agent is the function who manipulate the sample depending on the environment state. Both the reward and a the state are used as input from the agent in order to get decisions on next actions. The agent learns by the reward which depends about the reached state. For example the reward could be higher if the reached state is close to the desired one or vice-versa. The authors use a Q-Learning technique in order to underestimate a negative reward given for an action which would be significant in medium long term.

"In our framework, the actions space A consists of a set of modifications to the PE file that (a) don’t break the PE file format, and (b) don’t alter the intended functionality of the malware sample. The reward function is measured by the anti-malware engine, which is converted to a reward: 0 if the modified malware sample is judged to be benign, and 1 if it is deemed to be malicious. The reward and state are then fed back into the agent."

Final Considerations

Machine Learning, but more generally speaking Artificial Intelligence, would be useful to detect Cyber Attacks but unfortunately - as widely proved on this post - it would not be enough per se. Attackers would use the same techniques such as Adversarial Machine learning  to evade Machine Learning detectors. Cyber Security Analysts would still play a fundamental role in Cyber Security Science and Technology for many years from now. A technology who promises to assure cyber security protection without human interaction is not going to work.

Facial Recognition And Future Scenarios

Will facial recognition technologies mean we will be permanently under surveillance in the future? Should schools and colleges be teaching children how this technology works? Or should we just ignore this technology as if it wasn’t happening? Are there any alternatives?

Bejtlich on the APT1 Report: No Hack Back

Before reading the rest of this post, I suggest reading Mandiant/FireEye's statement Doing Our Part -- Without Hacking Back.

I would like to add my own color to this situation.

First, at no time when I worked for Mandiant or FireEye, or afterwards, was there ever a notion that we would hack into adversary systems. During my six year tenure, we were publicly and privately a "no hack back" company. I never heard anyone talk about hack back operations. No one ever intimated we had imagery of APT1 actors taken with their own laptop cameras. No one even said that would be a good idea.

Second, I would never have testified or written, repeatedly, about our company's stance on not hacking back if I knew we secretly did otherwise. I have quit jobs because I had fundamental disagreements with company policy or practice. I worked for Mandiant from 2011 through the end of 2013, when FireEye acquired Mandiant, and stayed until last year (2017). I never considered quitting Mandiant or FireEye due to a disconnect between public statements and private conduct.

Third, I was personally involved with briefings to the press, in public and in private, concerning the APT1 report. I provided the voiceover for a 5 minute YouTube video called APT1: Exposing One of China's Cyber Espionage Units. That video was one of the most sensitive, if not the most sensitive, aspects of releasing the report. We showed the world how we could intercept adversary communications and reconstruct it. There was internal debate about whether we should do that. We decided to cover the practice in the report, as Christopher Glyer Tweeted:

In none of these briefings to the press did we show pictures or video from adversary laptops. We did show the video that we published to YouTube.

Fourth, I privately contacted former Mandiant personnel with whom I worked during the time of the APT1 report creation and distribution. Their reaction to Mr Sanger's allegations ranged from "I've never heard of that" to "completely false." I asked former Mandiant colleagues, like myself, in the event that current Mandiant or FireEye employees were told not to talk to outsiders about the case.

What do I think happened here? I agree with the theory that Mr Sanger misinterpreted the reconstructed RDP sessions for some sort of "camera access." I have no idea about the "bros" or "leather jackets" comments!

In the spirit of full disclosure, prior to publication, Mr Sanger tried to reach me to discuss his book via email. I was sick and told him I had to pass. Ellen Nakashima also contacted me; I believe she was doing research for the book. She asked a few questions about the origin of the term APT, which I answered. I do not have the book so I do not know if I am cited, or if my message was included.

The bottom line is that Mandiant and FireEye did not conduct any hack back for the APT1 report.

Update: Some of you wondered about Ellen's role. I confirmed last night that she was working on her own project.

Alarming! : Windows Update Automatically Downloaded and Installed an Untrusted Self-Signed Kernel-mode Lenovo Driver on New Surface Device


Given what it is I do, I don't squander a minute of precious time, unless something is very important, and this is very important.

Let me explain why this is so alarming, concerning and so important to cyber security, and why at many organizations (e.g. U.S. Govt., Paramount Defenses etc.), this could've either possibly resulted in, or in itself, be considered a cyber security breach.

Disclaimer: I'm not making any value judgment about Lenovo ; I'm merely basing this on what's already been said.

As you know, Microsoft's been brazenly leaving billions of people and thousands of organizations worldwide with no real choice but to upgrade to their latest operating system, Windows 10, which albeit is far from perfect, is much better than Windows Vista, Windows 8 etc., even though Windows 10's default settings could be considered an egregious affront to Privacy.

Consequently, at Paramount Defenses, we too felt that perhaps it was time to consider moving on to Windows 10, so we too figured we'd refresh our workforce's PCs. Now, of the major choices available from amongst several reputable PC vendors out there, Microsoft's Surface was one of the top trustworthy contenders, considering that the entirety of the hardware and software was from the same vendor (, and one that was decently trustworthy (considering that most of the world is running their operating system,)) and that there seemed to be no* pre-installed drivers or software that may have been written in China, Russia etc.

Side-note: Based on information available in the public domain, in all likelihood, software written in / maintained from within Russia, may still likely be running as System on Domain Controllers within the U.S. Government.

In particular, regardless of its respected heritage, for us, Lenovo wasn't  an option, since it is partly owned by the Chinese Govt.

So we decided to consider evaluating Microsoft Surface devices and thus purchased a couple of brand-new Microsoft Surface devices from our local Microsoft Store for an initial PoC, and I decided to personally test-drive one of them -

Microsoft Surface

The very first thing we did after unsealing them, walking through the initial setup and locking down Windows 10's unacceptable default privacy settings, was to connect it to the Internet over a secure channel, and perform a Windows Update.

I should mention that there was no other device attached to this Microsoft Surface, except for a Microsoft Signature Type Cover, and in particular there were no mice of any kind, attached to this new Microsoft surface device, whether via USB or Bluetooth.

Now, you're not going to believe what happened within minutes of having clicked the Check for Updates button!

Windows Update
Downloaded and Installed an Untrusted
Self-Signed Lenovo Device Driver on Microsoft Surface! -

Within minutes, Windows Update automatically downloaded and had installed, amongst other packages (notably Surface Firmware,) an untrusted self-signed Kernel-mode device-driver, purportedly Lenovo - Keyboard, Other hardware - Lenovo Optical Mouse (HID), on this brand-new Microsoft Surface device, i.e. one signed with an untrusted WDK Test Certificate!

Here's a snapshot of Windows Update indicating that it had successfully downloaded and installed a Lenovo driver on this Surface device, and it specifically states "Lenovo - Keyboard, Other hardware - Lenovo Optical Mouse (HID)" -

We couldn't quite believe this.

How could this be possible? i.e. how could a Lenovo driver have been installed on a Microsoft  Surface device?

So we checked the Windows Update Log, and sure enough, as seen in the snapshot below, the Windows Update Log too confirmed that Windows Update had just downloaded and installed a Lenovo driver -

We wondered if there might have been any Lenovo hardware components installed on the Surface so we checked the Device Manager, and we could not find a single device that seemed to indicate the presence of any Lenovo hardware. (Later, we even took it back to the Microsoft Store, and their skilled tech personnel confirmed the same finding i.e. no Lenovo hardware on it.)

Specifically, as you can see below, we again checked the Device Manager, this time to see if it might indicate the presence of any Lenovo HID, such as a Lenovo Optical Mouse, and as you can see in the snapshot below, the only two Mice and other pointing devices installed on the system were from Microsoft - i.e. no Lenovo mouse presence indicated by Device Manager -

Next, we performed a keyword search of the Registry, and came across a suspicious Driver Package, as seen below -

It seemed suspicious to us because as can be seen in the snapshot above, all of the other legitimate driver package keys in the Registry had (as they should) three child sub-keys i.e. Configurations, Descriptors and Strings, but this specific one only had one subkey titled Properties, and when we tried to open it, we received an Access Denied message!

As you can see above, it seemed to indicate that the provider was Lenovo and that the INF file name was phidmou.inf, and the OEM path was "C:\Windows\SoftwareDistribution\Download\Install", so we looked at the file system but this path didn't seem to exist on the file-system. So we performed a simple file-system search "dir /s phidmou.*" and as seen in the snapshot below, we found one instance of such a file, located in C:\Windows\System32\DriverStore\FileRepository\.

Here's that exact location on the file-system, and as evidenced by the Created date and time for that folder, one can see that this folder (and thus all of its contents), were created on April 01, 2018 at around 1:50 am, which is just around the time the Windows Update log too confirmed that it had installed the Lenovo Driver -

When we opened that location, we found thirteen items, including six drivers -

Next, we checked the Digital Signature on one of the drivers, PELMOUSE.SYS, and we found that it was signed using a self-signed test Windows Driver certificate, i.e. the .sys files were SELF-SIGNED by a WDKTestCert and their digital signatures were NOT OK, in that they terminated in a root certificate that is not trusted by the trust provider -

Finally, when we clicked on the View Certificate button, as can be seen below, we could see that this driver was in fact merely signed by a test certificate, which is only supposed to be used for testing purposes during the creation and development of Kernel-mode drivers. Quoting from Microsoft's documentation on Driver Testing "However, eventually it will become necessary to test-sign your driver during its development, and ultimately release-sign your driver before publishing it to users." -

Clearly, the certificate seen above is NOT one that is intended to be used for release signing, yet, here we have a Kernel-mode driver downloaded by Windows Update and installed on a brand new Microsoft surface, and all its signed by is a test certificate, and who knows who wrote this driver!

Again, per Microsoft's guidelines on driver signing, which can also be found here, "After completing test signing and verifying that the driver is ready for release, the driver package has to be release signed", and AFAIK, release signing not only requires the signer to obtain and use a code-signing certificate from a code-signing CA, it also requires a cross cert issued by Microsoft.

If that is indeed the case, then a Kernel-mode driver that is not signed with a valid code-signing certificate, and one whose digital signature does not contain Microsoft's cross cert, should not even be accepted into the Windows Update catalog.

It is thus hard to believe that a Windows Kernel-Mode Driver that is merely self-signed using a test certificate would even make it into the Windows Update catalog, and further it seems that in this case, not only did it make it in, it was downloaded, and in fact successfully installed onto a system, which clearly seems highly suspicious, and is fact alarming and deeply-concerning!

How could this be? How could Windows Update (a trusted system process of the operating system), which we all (have no choice but to) trust (and have to do so blindly and completely) have itself installed an untrusted self-signed Lenovo driver (i.e. code running in Kernel-Mode) on a Microsoft Surface device?

Frankly, since this piece of software was signed using a self-signed test cert, who's to say this was even a real Lenovo driver? It could very well be some malicious code purporting to be a Lenovo driver. Or, there is also the remote possibility that it could be a legitimate Lenovo driver, that is self-signed, but if that is the case, its installation should not have been allowed to succeed.

Unacceptable and Deeply Concerning

To us, this is unacceptable, alarming and deeply concerning, and here's why.

We just had, on a device we consider trustworthy (, and could possibly have engaged in business on,) procured from a vendor we consider trustworthy (considering that the entire world's cyber security ultimately depends on them), an unknown, unsigned piece of software of Chinese origin that is now running in Kernel-mode, installed on the device, by this device's vendor's (i.e. Microsoft's) own product (Windows operating system's) update program!

We have not had an opportunity to analyze this code, but if it is indeed malicious in any way, in effect, it would've, unbeknownst to us and for no fault of ours, granted System-level control over a trusted device within our perimeter, to some entity in China.

How much damage could that have caused? Well, suffice it to say that, for they who know Windows Security well, if this was indeed malicious, it would've been sufficient to potentially compromise any organization within which this potentially suspect and malicious package may have been auto-installed by Windows update. (I've elaborated a bit on this below.)

In the simplest scenario, if a company's Domain Admins had been using this device, it would've been Game Over right there!

This leads me to the next question - we can't help but wonder how many such identical Surface devices exist out there today, perhaps at 1000s of organizations, on which this suspicious unsigned Lenovo driver may have been downloaded and installed?

This also leads me to another very important question - Just how much trust can we, the world, impose in Windows Update?

In our case, it just so happened to be, that we happened to be in front of this device during this Windows update process, and that's how we noticed this, and by the way, after it was done, it gave the familiar Your device is upto date message.

Speaking which, here's another equally important question - For all organizations that are using Windows Surface, and may be using it for mission-critical or sensitive purposes (e.g. AD administration), what is the guarantee that this won't happen again?

I ask because if you understand cyber security, then you know, that it ONLY takes ONE instance of ONE malicious piece of software to be installed on a system, to compromise the security of that system, and if that system was a highly-trusted internal system (e.g. that machine's domain computer account had the "Trusted for Unconstrained Delegation" bit set), then this could very likely also aid perpetrators in ultimately gaining complete command and control of the entire IT infrastructure. As I have already alluded to above, if by chance the target/compromised computer was one that was being used by an Active Directory Privileged User, then, it would be tantamount to Game Over right then and there!

Think about it - this could have happened at any organization, from say the U.S. Government to the British Government, or from say a Goldman Sachs to a Palantir, or say from a stock-exchange to an airline, or say at a clandestine national security agency to say at a nuclear reactor, or even Microsoft itself. In short, for absolutely no fault of theirs, an organization could potentially have been breached by a likely malicious piece of software that the operating system's own update utility had downloaded and installed on the System, and in 99% of situations, because hardly anyone checks what gets installed by Windows Update (now that we have to download and install a whopping 600MB patch every Tuesday), this would likely have gone unnoticed!

Again, to be perfectly clear, I'm not saying that a provably malicious piece of software was in fact downloaded and installed on a Microsoft Surface device by Windows Update. What I'm saying is that a highly suspicious piece of software, one that was built and intended to run in Kernel-mode and yet was merely signed with a test certificate, somehow was automatically downloaded and installed on a Microsoft Surface device, and that to us is deeply concerning, because in essence, if this could happen, then even at organizations that may be spending millions on cyber security, a single such piece of software quietly making its way in through such a trusted channel, could possibly instantly render their entire multi-million dollar cyber security apparatus useless, and jeopardize the security of the entire organization, and this could happen at thousands of organizations worldwide.

With full respect to Microsoft and Mr. Nadella, this is deeply concerning and unacceptable, and I'd like some assurance, as I'm sure would 1000s of other CEOs and CISOs, that this will never happen again, on any Surface device, in any organization.

In our case, this was very important, because had we put that brand new Surface device that we procured from none other than the Microsoft Store, into operation (even it we had re-imaged it with an ultra-secure locked-down internal image), from minute one, post the initial Windows update, we would likely have had a potentially compromised device running within our internal network, and it could perhaps have led to us being breached.

If I Were Microsoft, I'd Send a Plane

Dear Microsoft, we immediately quarantined that Microsoft Surface device, and we have it in our possession.

If I were you, I'd send a plane to get it picked up ASAP, so you can thoroughly investigate every little aspect of this to figure out how this possibly happened, and get to the bottom of it! (Petty process note: The Microsoft Store let us keep the device for a bit longer, but will not let us return the device past June 24, and the only reason we've kept it, is in case you'd want to analyze it.)

Here's why. At the very least, if I were still at Microsoft, and in charge of Cyber Security -
  1. I'd want to know how an untrusted Kernel-mode device driver made it into the Windows Catalog
  2. I'd want to know why a Microsoft Surface device downloaded a purportedly Lenovo driver
  3. I'd want to know how Windows 10 permitted and in fact itself installed an untrusted driver
  4. I'd want to know exactly which SKUs of Microsoft Surface this may have happened on
  5. I'd want to know exactly how many such Microsoft Surface devices out there may have downloaded this package 

Further, and as such, considering that Microsoft Corp itself may easily have thousands of Surface devices being used within Microsoft itself, if I were still with Microsoft CorpSec, I'd certainly want to know how many of their own Surface devices may have automatically downloaded and installed this highly suspicious piece of untrusted self-signed software.

In short, Microsoft, if you care as deeply about cyber security as you say you do, and by that I'm referring to what Mr. Nadella, the CEO of Microsoft, recently said (see video below: 0:40 - 0:44) and I quote "we spend over a billion dollars of R&D each year, in building security into our mainstream products", then you'll want to get to the bottom of this, because other than the Cloud, what else could be a more mainstream product for Microsoft today than, Microsoft Windows and Microsoft Surface ?! -

Also, speaking of Microsoft's ecosystem, it indeed is time to help safeguard Microsoft's global ecosystem. (But I digress,)

In Conclusion

Folks, the only reason I decided to publicly share this is because I care deeply about cyber security, and I believe that this could potentially have impacted the foundational cyber security of any, and potentially, of thousands of organizations worldwide.

Hopefully, as you'll agree, a trusted component (i.e. Windows Update) of an operating system that virtually the whole world will soon be running on (i.e. Windows 10), should not be downloading and installing a piece of software that runs in Kernel-mode, when that piece of software isn't even digitally signed by a valid digital certificate, because if that piece of software happened to be malicious, then in doing so, it could likely, automatically, and for no fault of its users, instantly compromise the cyber security of possibly thousands of organizations worldwide. This is really as simple, as fundamental and as concerning, as that. 

All in all, the Microsoft Surface is an incredible device, and because, like Apple's computers, the entire hardware and software is in control of a single vendor, Microsoft has a huge opportunity to deliver a trustworthy computing device to the world, and we'd love to embrace it. Thus, it is vital for Microsoft to ensure that its other components (e.g. Update) do not let the security of its mainstream products down, because per the Principle of Weakest Link, "a system is only as secure as is its weakest link."

By the way, I happen to be former Microsoft Program Manager for Active Directory Security, and I care deeply for Microsoft.

For those may not know what Active Directory Security is (i.e. most CEOs, a few CISOs, and most employees and citizens,) suffice it to say that global security may depend on Active Directory Security, and thus may be a matter of paramount defenses.

Most respectfully,

PS: Full Disclosure: I had also immediately brought this matter to the attention of the Microsoft Store. They escalated it to Tier-3 support (based out of New Delhi, India), who then asked me to use the Windows Feedback utility to share the relevant evidence with Microsoft, which I immediately and dutifully did, but/and I never heard back from anyone at Microsoft in this regard again.

PS2: Another small request to Microsoft - Dear Microsoft, while at it, could you please also educate your global customer base about the paramount importance of Active Directory Effective Permissions, which is the ONE capability without which not a single object in any Active Directory deployment can be adequately secured! Considering that Active Directory is the foundation of cyber security of over 85% of all organizations worldwide, this is important. Over the last few years, we've had almost 10,000 organizations from 150+ countries knock at our doors, and virtually none of them seem to know this most basic and cardinal fact of Windows Security. I couldn't begin to tell you how shocking it is for us to learn that most Domain Admins and many CISOs out there don't have a clue. Can you imagine just how insecure and vulnerable an organization whose Domain Admins don't even know what Active Directory Effective Permissions are, let alone possessing this paramount capability, could be today?

DMOSK Malware Targeting Italian Companies

Today I'd like to share another interesting analysis made by my colleagues and I. It would be a nice and interesting analysis since it targeted many Italian and European companies. Fortunately the attacker forgot the LOG.TXT freely available on the dropping URL letting us know the IP addresses who clicked on the first stage analysed stage (yes, we know the companies who might be infected) . Despite what we did with TaxOlolo we will not disclose the victims IP addresses and so the companies which might be infected. National CERTs have been involved and they've got alerted.  Since we believe the threat could radically increase its magnitude in the following hours, we decided to write up this quick'n dirty analysis focusing on speed rather than on details. So please forgive some quick and undocumented steps.

Everything started from an eMail (how about that ?!). The eMail we've got had the following body.

Attack Path
A simple link to a drive ( ) is beginning our first stage of infection. An eMail address is given as one parameter to the doc.php script which would record the IP address and the "calling" email  address belonging to the victim. The script forces the browser to download a .zip file which uncompressed presents to the victim a JSE file called: scan.jse.  The file is hard obfuscated. It was quite difficult to be able to decode the following stage of infection since the JavaScript was obfuscated through, at least, 3 different techniques. The following image shows the Obfuscated sample.

Second Stage: Obfuscated JSE
Unfortunately the second stage is not the final one. Indeed once de-obfuscated it we figured out that it was dropping and executing another file having the .SCR mimetype. From this stage it's interesting to observe that only one dropping URL was called. It's a strange behaviour, usually the attackers use multiple dropping URLs in order to get more chances to infect the victims. The found URL was the following one:

"url": ""

The JSE file dropped the Third Stage into \User\User\AppData\Local\Temp\38781520.scr having the following  hash: 77ad9ce32628d213eacf56faebd9b7f53e6e33a1a313b11814265216ca2c4745 which has been previously analysed by 68 AV but only 9 of them recognised as malicious generic file. The following image shows the VirusTotal analysis.

Third Stage: Executable SCR file

Unfortunately we are still not at the end of the infection Stage. The Third stage drops and executes another payload. It does not download and execute from a different dropping website but it drops from a special and crafted memory address (fixed from .txt:0x400000). The following image shows the execution of the Fourth Stage payload directly from the victim's memory

Fourth Stage: Dropped PE File
Following the analysis it has been possible to figure out that the final payload is something very close to ursnif which grabs victims email information and credentials. The following image shows the temporary file built before sending out information to Command and Controls servers.

Temporary File Before Sending data to Command and Control

Like any other ursnif the malware tries to reach a command and control network located both on the clearnet and on the TOR network. A following section will expose the recorded IoCs.

An interesting approach that was adopted by attackers is the black listing. We observed at least 3 black lists. The first one was based on victims IP. We guess (but we have not evidences on that) that the attacker would filtering responses based on Country in order to make possible a country targeted attack by blacklisting not-targeted countries. The following image shows the used temporary file to store Victim IP. The attacker could use this information in order to respond or not to a specific malware request.

Temporary File Storing IP Victim IP Address

A second black list that we found was on the dropping URL web site which was trained to do not drop files to specific IP addresses. The main reasons found to deny the dropping payload were three:
  • geo (Out of geographical scope). The threat is mainly focused to hit italy.
  • asn (internet service providers and/or cloud providers). The threat is mainly focused on clients and not on servers, so it would have no sense to give payload to cloud providers.
  • MIT. THe attacker does not want the dropping payload ends up to MIT folks, this is quite funny, isn't it ?
A small section of black listing drop payload  

The black lists are an interesting approach to reduce the chance to be analysed, in fact the black listed IPs belong to pretty known CyberSecurity Companies (Yoroi is included) which often use specific cloud providers to run emulations and/or sandboxes. 

Personal note: This is a reverse targeting attack, where the attacker wants to attack an entire set of victims but not some specific ones, so it introduces a blocking delivery of payload technique. End personal note.

Now we know how the attack works, so lets try to investigate a little bit what the attacker messed out. For example lets try to analyse the content of the Dropping URL. Quite fun to figure out the attacker let freely available his private key ! I will not disclose it .... let's say... for respect to the attacker (? really ?) 

Attacker Private Key !

While the used public certificate is the following one:

Attacker Certificate

By decoding the fake certificate the analyst would take the following information, of course none of these informations would be valuable, but make a nice shake of analysis .

Common Name: test.dmosk.local
Organization: Global Security
Organization Unit: IT Department
Locality: SPb
State: SPb
Country: RU
Valid From: June 5, 2018
Valid To: June 5, 2022
Issuer: Global Security
Serial Number: 12542837396936657430 (0xae111c285fe50a16

Maybe the most "original string", by meaning of being written without thinking too much from the attacker, on the entire malware analysis would be the string  "dmosk" (in the decoded certificate), from here the Malware name.

As today we observed: 6617 eMail addresses that potentially could be compromised since they clicked on First stage (evidences on dropping url). We have evidences that many organisations have been hit from this malware able to bypass most of the known security protections since it was behind CloudFlare and with not a specific bad reputation. We decided to not disclose the "probably infected" companies. Nation Wide CERTs have been alerted (June 7 2018) and together we will contact the "probably infected" companies to help them to mitigate the threat. 

Please update your rules, signature and whatever you have to block the infection.

PS: the threat is quite a bit bigger than what I described, there are several additional components including APK (Android Malware), base ciphers, multi stage obfuscators and a complete list of "probably infected" users, but again, we decided to encourage the notification speed rather than analysis details. 

Hope you might find it helpful.

  • Dropurl:
    • https:// drive[.carlsongracieanaheim[.com/doc.php
    • https:// drive[.carlsongracieanaheim[.com/doc1.php
    • https:// drive[.carlsongracieanaheim[.com/x/gate.php
    • https:// drive[.carlsongracieanaheim[.com/1/gate.php
  • C2 (tor):
    • https:// 4fsq3wnmms6xqybt[.onion/wpapi
    • https:// em2eddryi6ptkcnh[.onion/wpapi
    • https:// nap7zb4gtnzwmxsv[.onion/wpapi
    • https:// t7yz3cihrrzalznq[.onion/wpapi
  • C2:
    • https:// loop.evama.[at/wpapi
    • https:// torafy[.cn/wpapi
    • https:// u55.evama[.at/wpapi
    • https:// yraco[.cn/wpapi
    • https:// inc.robatop.[at/wpapi
    • https:// poi.robatop.[at/wpapi
    • https:// arh.mobipot.[at/wpapi
    • https:// bbb.mobipot.[at/wpapi
    • https:// takhak.[at/wpapi
    • https:// kerions.[at/wpapi
    • https:// j11.evama[.at/wpapi
    • https:// clocktop[.at/wpapi
    • https:// harent.[cn/wpapi
  • Hash:
    • 067b39632f093821852889b1e4bb8b2a48afd94d1e348702a608a70bb7b00e54 zip
    • 77ad9ce32628d213eacf56faebd9b7f53e6e33a1a313b11814265216ca2c4745 jse
    • 8d3d37c9139641e817bcf0fad8550d869b9f68bc689dbbf4b4d3eb2aaa3cf361 scr
    • 1fdc0b08ad6afe61bbc2f054b205b2aab8416c48d87f2dcebb2073a8d92caf8d exe
    • afd98dde72881d6716270eb13b3fdad2d2863db110fc2b314424b88d85cd8e79 exe
  • Cert:


KWA UFUPI: Kutokana na ukuaji wa teknolojia pamoja na muunganiko wa vitu vingi katika mtandao (IoT) vifaa vingi vya watoto vimekua mhanga mkubwa wa uhalifu mtandao – Hii imepelekea kuchukuliwa kwa hutua mbali mbali za kulinda watoto mitandaoni. Andiko hili lina angazia namna bora ya kulinda vifaa vya watoto vya TEHAMA.

Kumekua na matukio kadhaa yaliyo husisha kuingiliwa kimtandao (kudukuliwa) kwa vifaa vinavyo tumiwa na watoto huku wahalifu mtandao wakiunda program tumishi zenye nia ovu ya kukusanya picha na sauti za watoto.

Mfano, kampuni ya V-Tech ambayo inatengeneza vifaa vya TEHAMA vya watoto Ilipata kudukuliwa na wahalifu mtandao ambapo taarifa nyingi za watoto zilijikuta mikononi mwa wahalifu mtandao.

Shirika la umoja wa mataifa linalo husiana na TEHAMA (ITU) limekua na kampeni maarufu ya Kuwalinda watoto mtandaoni – Child online protection (COP) ambayo imeongezewa nguvu na Kampeni nyingine ya wanausalama mtandao ijulikanayo kama siku ya usalama mtandao “Safer internet day” ambazo kwa pamoja zinatoa msaada ingawa kuna kila sababu kwaa wazazi nao kuchukua hatua kuwalinda watoto wao kimtandao.

Taarifa zinaonyesha wazazi wengi wamekua wakinunua vifaa kama vile – midoli ya kimtandao (smart toys), Vifaa vya kuwafatilia wototo (baby monitors), na vifaa vingine vya kuchezea (high-tech swings na play pads) vyote vikiwa vimeunganishwa katika mitandao.

Ikumbukwe, vifaa hivi vyote pamoja na kuonekana kuwapatia watoto furaha pamoja na kuwaweka wazazi karibu na watoto wao pia vinaongeza hatari kubwa ya kuweza kusababisha uhalifu mtandao kwa watototo – tumeendelea kuwaasa wazazi kua makini kwenye haya.

Wazazi wengi wamekua wakieleza vifaa hivi vimekua vikiwasaidia kuweza kujua hali za watoto wao (Mfano: Kujua joto lao la mwili la mtoto, mapigo ya moyo ya mtoto nakadhalika) huku wakiweza kuwafatilia watoto wao kwa kuwaona kwa ukaribu ingawa wako mbali nao kupitia vifaa hivi vya kisasa – Ni sahihi kua hili si jambo baya kwa mzazi kwani inampa faraja kujua mtoto wake anaendeleaje mda wote hata kama yuko mbali.

Ifahamike kua, wahalifu mtandao wame endelea kuingilia vifaa hivi kwa nia mbali mbali – Wengine wanafatilia tu familia za watu na njia rahisi ni kupitia vifaa hivi vinavyo weza kudukuliwa kirahisi, na wengine ni katika kukusanya tu taarifa za watoto ambazo wamekua wakizitumia vibaya.

DONDOO:  Namna unavyoweza kulinda vifaa hivi vya watoto dhidi ya uhalifu mtandao.

Tafakari kabala ya kununua:Kabla ya mzazi kununua vifaa hivi ni vyema ukajiuliza maswali muhimu – Je, Unaulazima wa kua navyo, vinaathari gani kwenye taarifa za familia, unauwezo wa kuvilinda, vimeunganishwa kwenye mtandao kwa kiasi gani, vimeundwa na nani na vina ulinzi kiasi gani.

Badili neon siri (Nywila) linalo kuja na vifaa hivyo (Default password): Vifaa hivi vya ki TEHAMA vya watoto vinakuja na Maneno siri ambayo wahalifu mtandao mara nyingi wanakua tayari wanayajua au ni rahisi kuya pata – Inashauriwa kama umenunua ni vizuri ukabadili maneno siri hayo na kuweka mengine madhubuti ambayo utakua ukibadili mara kwa mara kama kifaa kitaruhusu ili kulinda vifaa hivyo.

Nunua vifaa vivi kutoka kwenye makampuni yenye sifa (Known brand – with reputation):Kumekua na makampuni mengi ambayo yamekua yakitoa vifaa pamoja na program tumishi zenye nia ovu ya kukusanya taarifa za watoto

Aidha, Kunayo makampuni ambayo yamekua na udhaifu katika kulinda vifaa wanavyo tengeneza kwa ajili ya watoto – Inashauriwa uhakiki unajiweka mbali na aina hizo za makampuni ili usijikute eidha, ulicho nunua kinapelekea taarifa za mtoto (Picha na sauti) kutumiwa vibaya au kampuni inadukuliwa mara kwa mara na kupelekea taarifa za watoto kua hatarini.

Boresha program (Update software):Kama ilivyo kwa program nyingine, panapo gundulika mapungufu watengenezaji hutoa maboresho ambayo yanamtaka mtumiaji kuyaongezea kwenye vifaa wanavyo tumia ili viendelee kua na ulinzi – Kwenye vifaa vya watoto pia inapaswa wazazi wawe na tabia ya kuboresha programu zake kila mara zinapo boreshwa na watengenezaji/ waundaji wa vifaa hivyo.

Zima kama hutumii: Vifaa hivi vinapokua vimezimwa vinapunguza mwanya kwa wahalifu mtandao kuvidukua au kuviathiri, hivyo inashauriwa kama kifaa cha mtoto cha kitehama ukitumii basi kizime – Hii itasaidia kupunguza wimbi la uwezekano wa kudukuliwa au kuingiliwa kwa faragha za watoto na familia kwa ujumla.