>Oh joy — wifi issues on Windows 7

>This has been driving me nuts lately… Ever since I went back on Windows 7 I’ve had a crap-load of trouble with it storing my wifi connections. I have at least 5 locations that I visit on a regular basis and as you can imagine it’s a pain to have to re-key the wifi password every time.

I think I’ve finally found the source of my problem: I have multiple virtual adapters for each of my VPN technologies – these seem to prevent my wifi adapter from kicking in and finding my connection.

How do you fix this? Go into the Network and Sharing Center, hit “change adapter settings”, press the ALT key and go into Menu > Advanced Settings. In the Adapters and Bindings tab, move the adapters around so that your ethernet adapter is first, then your wireless connection, then all the other adapters.

Now, that seemed to do the trick for me. Will let you know if this sticks, but if anyone has any other suggestions (apart from the obvious and inevitable switch back to Linux) I’m all ears!!!

I promised myself that I would never return to a Windows environment. I find myself breaking that promise because of development needs… With some luck this is a temporary situation 🙂

>Quick analysis of a trojan targetting swiss users

>

We’ve seen a couple of cases of this trojan hitting client computers lately; unfortunately, the security bulletin by the CYCO doesn’t have much yet in terms of information on IP addresses, domain names, or what else the trojan might be doing in the background, so I dusted off the old forensics toolkit and did a bit of digging.
Look at this bad boy! Innit unreal? Brilliant 🙂 I knew this kind of stuff was around but I must admit it’s the first time I encounter ransomware this targeted…

My colleague confirmed that this was only happening on the user’s account – not the local admin account present on the computer. So the first thing we did was run Sysinternals’ Process Monitor to identify what was causing the screen to appear. Note that we use Deep Freeze on users’ computers and the machine was frozen at the time of the infection, so it was likely that what was running was persisted on the user’s drive. I really wish that we could freeze everything but the user’s Desktop, My Docs, and Favorites – however, that seems to royally piss off our users. Would have prevented this from happening though.  Anyway, moving on. If you know that the only location where this executable could possibly exist is the user’s drive, it’s easy to identify the culprit:

No big surprise there — it’s running in the user’s Temp folder. Unsurprisingly as well, the user’s SoftwareWindows NTCurrentVersionWinlogon file has been modified to point the shell to that upd executable – that’s easily sussed out by using regripper or regdump. With regripper, we even get a timestamp of when this was done which will be useful for cross-referencing information later. 
OK great, so now we know where this thing is – how did it get there?
It was a bit harder to figure out how the hell the trojan got on the user’s computer, I’ll admit. I used Web Historian at first to identify any suspicious sites. I don’t know about the rest of you out there, but my experience is that when malware shows up on users’ computers, it’s typically because they’ve been downloading something illegal or, er, carnal. However, when looking at the user’s web history no alarm bells were going off. All good, clean, unremarkable sites. I went as far as to investigate the user’s mail store to see if the machine could have gotten infected by email – nothing suspicious there either. USB keys would have left a trace in the registry but since the machine was frozen, I wouldn’t be able to figure out if a key was inserted at the time of the infection. I therefore switched tactics and ran a timeline analysis of the user drive using sleuthkit. That’s when I found this:

The same minute the executable was written, something was written to the Java cache. Coincidence? Yeah right. I took a look at the index file, guess what I found?

If you decompile the JAR using jad, you get something like this:

If you check out the domain and IP address written in the index file, you’ll see that the domain is registered to a Russian registrant; the IP address traces back to the domain, but is hosted in the Netherlands.
That’s all the JAR file seems to do. I haven’t messed around with the upd.exe file yet, will probably do so sometime soon. In the meantime, I hope that you found this entertaining 😀 Should I be looking at anything else? Let me know.

>Ironkey settings stick, even in read-only mode

>I am writing this post as a bit of a sanity check, perhaps someone out there can help me by comparing notes or providing explanations 🙂

Yesterday, I was using my IK to perform a memory dump for forensic analysis on a system infected with a trojan. I’ve used a CD for this in the past but figured “why not just use my IK in read-only mode” — I popped my IK in, making sure I ticked the [I]read-only mode[/I] checkbox. No problems there, of course. Performed a memory dump, which I wrote to a throw-away USB stick, then ejected my IK.

You know how your settings stick from one session to another? I figured this was recorded when the IK checked into the management console. However, when I popped my IK into another machine this morning, I noticed that the settings had stuck.

When I do my forensic analyses, they are in a different location than client sites – this is why I am 100% certain that the machine was not connected to the Internet – wifi was off in any case (though the wifi switch on laptops is sometimes software-managed) but even if it were on, the machine wouldn’t have any AP to connect to. No ethernet or bluetooth connection either, of course.

My theory, therefore, is that the settings are stored on some RW volume on the IK. Can anyone tell me more about this? Is there some part of the manual that I’ve overlooked? What gets written to that volume? What FS does it have, and can it be infected with malware? This would be disconcerting.

Any insight would be very much appreciated 🙂