Okay, okay...the title of this post isn't the greatest, I get it...but no pun intended. Anyway, I left it as is because (a) I couldn't think of anything witty, and (b) it is kinda funny.
Anyway, on with the show...
I was looking at an issue recently and I came across the following statement in a malware write-up:
It also creates a hidden user account named "HelpAssistant" and creates the following hidden folder: C:\Documents and Settings\HELPASSISTANT
Hhhmmm. Okay, so an artifact for an infected system is this hidden user account...interesting. So I go to a command prompt on my Windows XP box and type net user, and I get a list of user accounts on my system, one of which is HelpAssistant. Wow. So does that mean I'm infected?
Well, the next thing I do is export the Registry hive files from my system and hit the SAM hive with the samparse.pl RegRipper plugin, and I see:
Username : HelpAssistant [1000]
Full Name : Remote Desktop Help Assistant Account
User Comment : Account for Providing Remote Assistance
Account Created : Mon Aug 7 20:23:36 2006 Z
Last Login Date : Never
Pwd Reset Date : Mon Aug 7 20:23:36 2006 Z
Pwd Fail Date : Never
Login Count : 0
--> Password does not expire
--> Account Disabled
--> Normal user account
Okay, so this is a normal user account, never logged in, and appears to have been created in 2006. I think that this is interesting, because I installed this system in Sept, 2009. It appears that this is a default account that's set up with some settings already set to specific values.
Now, a little research tells me that this is an account used for Remote Assistance. If that's the case, does malware create or take over the account? It's possible, with the appropriate privileges, to use the API (or the net user commands) to delete and then create the account. To see if this is what happened, you may be able to find some information in the Event Log (assuming the proper auditing is enabled...) having to do with account deletion/creation. Another analysis technique is to examine the RID on the account as RIDs are assigned sequentially, and to check the unallocated space within the SAM hive (using regslack) to see if the original key for the HelpAssistant account was deleted.
What about this hidden thing? Well, as the write-up never states how the account is hidden, one thing to consider is that the fact that it's hidden is part of normal system behavior. That's right...Windows has a special Registry key that tells it to hide user accounts from view on the Welcome screen, essentially making those accounts hidden. Win32/Starter and Win32/Ursnif both take advantage of this key.
This is just another example of how AV write-ups can be incomplete and misleading, and how responders and analysts should not allow themselves to be mislead by the information provided in these write-ups.
13 comments:
This does not surprise me at all! AV companies are so often wrong about their scan results with false positive file or website virus detection. I believe they do very little diligence.
Even after you contact them on some hidden report page, tell them what the file is and they remove it from their detection list there no guarantee that they will not detect it as a threat at a later date. All you can do is apply to have your name cleared by them again. Guilty until proven innocent with these guys.
They are total immune from the consequences of a false positive or shoddy work. I think this makes their work lax across the entire range.
While I agree that what they post can be misleading, I also realize that they aren't in the business of incident response, per se...so they aren't focused on such things.
When a customer infrastructure is infected, most often the AV vendor's approach is to get sample, generate a signature and then roll it out to all systems. Many times, what ends up happening is that other responders will scan the domain for Registry or file system artifacts, and then clean individual systems.
well, you may not post this answer as you may find it not up to your taste, but while there is a lot you can say about incident response and forensics, there is not so much you can say about how AV companies work; writeups are often autogenerated, and for these where the manual input is provided, it's often junior researchers who work on them; then the writeups go through QA and reviews, yet you can't avoid problems coming from a simple fact that a) researcher doesn't know everything b) a person who reviews it, doesn't know everything; finally, the AV writeups are pretty much at the bottom list of priorities; automation and batch sample processing - _ensuring_ the product detects and removes malware properly in a first place and with no issues - is far more important than writeups; these who actually read and use writeups and do not rely on the product itself are people who are at least experienced or power users... like you
...there is not so much you can say about how AV companies work...
You're right, because I don't know. I do know that, as an incident responder trying to assist a customer, and as an analyst trying to answer a question for a customer, I've had issues with what's in the write-ups.
Thanks for your comments.
thanks for posting my post; I appreciate that and apologies if it sounded like a personal attack;
would you agree that writeups should be completely ignored by IRs/FIs? Or, more practically, disqualified as "proper" evidence and treated like hearsay? The fundamental problem is not the writeups itself, but the approach that assumes these writeups are a reliable source of information; for reasons outlined in my previous post (I could add some more e.g. how many different samples are covered by one writeup, how many completely different malware samples are qualified by accident/mistake as the same sample and then writeups modified accordingly, etc.), they shouldn't be treated as such; in other words, there are no shortcuts and IRs/FIs need to learn proper malware analysis; and by "proper", I mean the ability to fully analyse what that piece of code is doing (on the code level, not dynamic and static analysis only that is often misleading), and the ability to make informed decisions when various reasons make such analysis impossible or not worthy
I just finished an incident that included malware like this. My understanding is that HelpAssistant is created when a Remote Assistance session is activated. It shouldn't normally have a profile under \Documents and Settings.
iamnowonmai
My understanding is that HelpAssistant is created when a Remote Assistance session is activated. It shouldn't normally have a profile under \Documents and Settings.
Thanks for the comment.
More correctly, the HelpAssistant user account is on the system, in the SAM...however, no user profile is created until someone logs into the system via that account.
You can test/verify this by creating a user account on your system with net user /add, and then observing the user profile directory for several days, across reboots. Then, log into the system using that account; you will be able to verify that the profile was not created until you actually logged in using that account.
Though using Remote Assistance requires the HelpAssistant account, I've never observed a profile created for this account under Documents and Settings even after a Remote Assistance session. It doesn't appear in the ProfileList key and is only listed under SpecialAccounts in HKLM. There are a few mentions of it in HKU under systemprofile's hive (S-1-5-18) so that might be the profile it uses. I don't think it would be possible to log in directly with this account, or take it over.
I played with it a little on my VM and found that it's possible to delete the account, breaking Remote Assistance. It will not be recreated automatically and you must boot into Safe Mode and run sessmgr.exe -service (as instructed by a helpful error message in the Application Viewer from RemoteAssistance) to restore it. I imagine that with the account deleted you should be able to create your own HelpAssistant account, but the difference should be very, very obvious.
But it wouldn't be obvious, as you were saying, to a regular user, and I can imagine someone creating a jdbgmgr-like hoax out of it.
--Shanna
This post is interesting to me as I just completed an investigation where Mebroot had been installed on several systems. I also believe that Symantec is correct (eventhough I do not agree with how they worded it) that the HelpAssistant profile is a Mebroot infection artifact. It was common between all of these systems that I performed analysis on that the HelpAssistant profile directory was created (including the appropriate sub directories) and done so at the time of infection.
I think that the breakdown is that they are stating that the account is created by mebroot, when it should state that the Help Assistant profile directory is created as part of mebroot infection.
I agree...I am currently analyzing a Mebroot infected system myself.
I've noticed that almost the entire content of the HelpAssistant profile has been copied from the profile of the user that was active/logged in on the system when the infection occurred. I created a timeline and it seems to indicate that this is the case. In fact, when I run RegRipper against the user hives, I get almost identical contents there, as well.
Case study I saw linked on Gadi Evrons blog regarding investigating anamolous data when AV says it aint:
http://www.cyberwart.com/blog/2010/01/09/undetected-malware-case-study-jan2010-01/
Besides, Case study postings r0x
I've noticed that almost the entire content of the HelpAssistant profile has been copied from the profile of the user that was active/logged in on the system when the infection occurred. I created a timeline and it seems to indicate that this is the case.
My timeline agrees with that. With the exception of HelpAssistant/Templates which has roughly the same timestamp as the system load.
iamnowonmai
Interesting.
What about other artifacts, such as the HelpAssistant account information in the SAM database, and maybe even Event Log records?
I'm going to see about doing a write-up on this, from the overall analysis conducted.
Post a Comment