The Dutch and the Dorifel

Unless you happen to live in the Netherlands, chances are that you missed the outbreak of a ‘new’ piece of malware a few weeks ago called Dorifel, also known as XDocCrypt. With over 3000 infections in a matter of hours, of which 90% were systems in the Netherlands, this triggered the Dutch National Cyber Security Center almost instantly. XDocCrypt/Dorifel is a new trojan that encrypts executables, Excel- and Word files that it finds on USB drives and network disks, causing companies to come to a grinding halt almost immediately after infection. Later investigation by Digital Investigations turned up that it also distributes phishing banking websites for ING Bank, ABN AMRO and SNS Bank (all banks with a strong presence in the Netherlands). With such distinctive traits, you would expect that it would be ransomware, but it’s not. It doesn’t ask for money, and there are no real clues what the point is of encrypting those files. It may simply have been a trial run just to find out how good this technique works, but it’s all conjecture at this point.

As an aside, it should be mentioned that the malware’s efforts in encryption did uncover something I found interesting: it exploits the RTLO Unicode Hole, which uses a Windows standard Unicode “Right-to-left override” that are more commonly used in Arabic and Hebrew texts (meaning it’s a Feature, not a Bug). Through this use of the RTLO Unicode Hole, they make filenames such as testU+202Ecod.scr appear in the Windows Explorer as testrcs.doc, and effectively make a harmful executable look like a simple Word doc.

What worries me most, and this is the reason for this article, is the delivery vehicle used by this new piece of malware. You see, it doesn’t exploit some new weakness. Instead, it’s being delivered by systems previously infected with the Citadel/Zeus trojan. This means that over 3000 systems in the Netherlands –systems belonging mostly to ministries, local government and hospitals- already had active botnets inside their networks before getting infected with this new malware! Mind you, virtually all of these systems and networks had active antivirus and IDS systems, and NONE detected either the Citadel/Zeus botnet already in place, nor the new XDocCrypt/Dorifel malware. If anything should be a severe wake-up call for Dutch firms who still half-ass their security, this is it.

Major AV vendors such as Kaspersky and McAfee now address this piece of malware, but it does make you wonder: If this Trojan hadn’t gone through the trouble of encrypting all those files, would it ever have been caught? Clearly, with only a couple of thousand infections, it is not that big of an outbreak. Chances are good that Dorifel would have stayed below the “economic feasibility to fix” line that most antivirus corporations adhere to. With malware code mutation getting increasingly easier and more mature, will this be our future? No more large infections, but a lot more small ones to stay below the collective AV radar? It seems plausible. It certainly makes the dim future of the current AV Modus Operandi that much dimmer. When will we finally see a paradigm shift in our approach to defeating malware?

Account sync revisited

Despite things being fairly hectic here on the project right now, I’d like to revisit a previous post. Our beloved Account Sync problem turned up again! It is now clear that my last post on the matter was incomplete. While it is still true that the R2 upgrade gave us problems, the full explanation is more complicated.

So, what part did the upgrade to R2 cause?
The upgrade of our domain controllers to Server 2008 R2 caused the Quest Migration Manager to simply stop connecting to the domain entirely. We could no longer migrate accounts and there was no longer any syncing of any kind. We investigated the Windows Firewall rules closely, expecting it to be the cause, but eventually established that our ruleset was fine. Quest tech support couldn’t find anything wrong there either, and we decided it would probably be simpler to just install a new virtual Server 2008 domain controller. They would start supporting R2 in the next QMM version that was due to come out this december and we’d upgrade our version then.

 Then what?
After putting the Server 2008 domain controller in place, account migration and domain synchronisation was back on track. It wasn’t till a few days later -when we had to migrate accounts again- that we discovered our old account synchronisation problem had reared its ugly head again. It now became obvious that this wasn’t being caused by having an R2 domain controller. We reopened our case with Quest and started investigating.

sync00Quest Account Synchronisation
By default, Quest Migration Manager uses a couple of methods to establish synchronisation between accounts. It checks the Account Name (samAccountName) and the email address between the source and target account and also tries to match the source accounts’ SID with the target accounts’ SIDHistory field.  

You can find these settings when configuring the Domain Pair. In the image on the left, all three options are enabled. However, we stopped trusting our SIDHistory when we discovered multiple accounts had multiple SIDHistory entries so we turned SIDHistory matching off for now.


Microsoft .NET 3.5 versioning and IIS 7

We just had an interesting discussion here that I find worth mentioning. A colleague was trying to figure out how to select and/or enable .NET 3.5 on his Server 2008 machine running IIS 7. He asked me where to look, but im not really a webserver expert so I had to look it up myself.

Imagine my surprise when I found out that Microsoft .NET 3.5 is merely a combination of the .NET 2.0 runtime with some additional libraries. You cant actually select 3.5 because…well…technically it doesn’t exist!

My information comes from various sources, so feel free to check out the following sites for more information:

Rick Strahl’s blog
Blogs at MSDN

Quest Migration Manager synch

The issue I wrote about in my previous post about the faulty synchronization between useraccounts turns out to have been caused by a recent upgrade to Windows Server 2008 R2.  Despite the local firewall settings that we put in place, the QMM server was still unable to connect to the Migration Agent on that DC. At Quest they couldn’t exactly tell me what the problem with this OS is, but that their next version (8.5) would support 2008 R2.  After installing a new DC running 2008 and pointing QMM to this server for its migration activities, the issues disappeared.

While waiting for what would eventually turn out to be the solution (install a 2008 DC), I went looking for a way to manually fix the sidHistory issue.

ADUC Attribute Editor tab

ADUC Attribute Editor tab

Microsoft added this wonderful extra tab in 2008’s Active Directory Users and Computers called Attribute Editor, which is basically AdsiEdit in a single tab. Despite appearances, you cant edit sidHistory directly through the GUI.

Searching the internet I discovered that there really isn’t that much information on this topic yet. Most of it seems geared towards Windows 2000 and 2003, but Server 2008 is a fairly different animal altogether. Under the hood, Directory Services still looks and acts largely the same as its predecessors, but scripts made for Windows 2000 will likely fail.

The Attribute Editor tab appeared to be the solution for my problem, but sidHistory is a protected field because of its possible security implications. According to Microsofts’ Technet article (also oriented on Windows 2000) you can only access it through a special API called DsAddSidHistory. Sadly, the article is lengthy, confuzing and in the end doesn’t tell you how to actually use it.

Next stop: Google.

True to form, a query for DsAddSidHistory on Google gives me results I could work with. Apparently in Windows Server 2003’s Support Tools there’s a set of scripts by ClonePrincipal that is geared towards assisting in migrating users with ADMT. One of the scripts included (sidhist.vbs) allows you to fill the sidHistory field with the SID from a source account. Both the Technet article and this ClonePrincipal page talk about having the same requirements for getting the script to work.Despite appearances, you cant add sidHistory through the GUI.

I never actually tried to use this script because Quests’ fix seemed to solve my immediate problems, so im not entirely certain this works for Server 2008. However, it too me considerable effort to find what I needed so I uploaded it for you. You can find the Windows Server 2003 Support Tools Cabinet file containing all the scripts here. Check the previous links on how to use it.

Quest Migration Manager 8.4 sync issue

I alluded to a bug in Quest Migration Manager for AD version 8.4 in my previous post that deserves a little more attention. Also, the solution might serve someone.

The problem:
Accounts on the target domain migrated with Quest Migration Manager 8.4 using sidHistory keep getting synced with faulty information.

Further inspection will reveal that the target account has not one, but several SID’s. For some unknown reason Quest takes both the SID of the source account as well as the SID of the lookalike account the source account was made from, and sticks that in the sidHistory field of the target account. This causes QMM’s Directory Synchronization to get confused and cram information from two (sometimes even more) seperate source accounts into one target account.

The Solution:
The obvious solution would be to just remove the incorrect SID’s through ADUC (thanks to the new tab introduced in Server 2008 – yay!) or ADSIEdit, but when we tried doing this we repeatedly received an error that we did not have sufficient rights. This happened despite the fact that the accounts we tried doing this with were all copies of the original Administrator account and were a member of builtin Administrators, Domain Admins, Enterprise Admins and Schema Admins!

Searching the internet yielded little but a few vague posts (there isn’t that much content on Server 2008 R2 yet…), only one of which sounded plausible, but it was about Server 2003. That poster mentioned that the sidHistory field was a protected field which only accepted input from a few processes/methods, and pointed to a VB script Microsoft released to clear the sidHistory. The download (a zip file) also included a VB script to display the object SID.

I have uploaded this zipfile to the site, you can download it here.

(I wish I could give credit to the original site I found it on, but sadly I dont remember. If anyone knows, let me know and i’ll attribute.)

Using the scripts in this zipfile I was able to clear the SID’s from sidHistory -each run removes 1 SID from sidHistory, not all SID’s are removed at once!- and re-migrate the accounts using QMM. Because the account already exists, it simply syncs the missing information. In this case, that would be the SID in sidHistory, and thats what we need so this works out just fine. After this was all done, we did not encounter any more problems with syncing.

Note: We did not encounter this issue before updating from version 8.3 to 8.4, and therefor assume the bug was introduced in this version.

Quest Migration Manager for AD and account deletions

Yesterday something odd happened at my current project. A user approached me with two usernames who had been migrated in the week before suddenly couldn’t log in anymore. These same two users had had synchronisation issues earlier due to a bug in Quest Migration Manager; due to Migration Manager copying the source account to the target domain (with sidHistory) but adding multiple SID’s instead of just one. This confused QMM and caused skewed syncing between the source and target account.

Now these same two accounts are suddenly deleted.

In my opinion this is not coincidence. The new domain we are migrating to is running on Windows Server 2008 R2 and im positive that this domain is set up properly. I also trust my colleagues to not have deleted these accounts manually without informing anyone, after all: why would they?

Sadly, I cant prove or disprove manual deletion because the DC’s security log was overwritten with newer events (something which we corrected right away) and a ticket with Quest was returned to us with the expected claim of innocense. I say Expected because I am aware that accidental account deletion would be a bug and not a feature so naturally their support desk would deny QMM to be at fault at the first glance.

To be continued.