Security Ripcord

Most of the time the initial infection vector associated with APT-style attacks incorporate the client-side exploitation of vulnerabilities in any number of software.  Actually, when dealing with APT-style events I prefer “initial compromise vector” (ICV) as APT backdoors should not be considered or even referred to as malware because it provides an incorrect understanding to the whole incident response.  User and system activity coupled with the fact that many organizations do not detect a compromise for several months means that the ICV can be elusive.  It is much more likely that the actions following the initial compromise are going to persist over time.

The following timeline information was pulled from a system.  A complete timeline was generated using system artifacts parsed using System Combo Timeline and several TLN-based Enscripts.  Each line is in the order display within the timeline.  no lines have been removed.  This was a fairly lucky situation as many times unrelated activity needs to be purged from the timeline to see this type of detail and understand specific activities.  Specific comments will follow the lines I want to highlight.

2009 11 04 08:59:42|SysEvent.Evt – EVT|COMP-SYS|S-1-5-18|Service Control Manager/7035;Info;LiveUpdate,start
2009 11 04 08:59:42|SysEvent.Evt – EVT|COMP-SYS|N/A|Service Control Manager/7036;Info;LiveUpdate,running
2009 11 04 09:00:06|AppEvent.Evt – EVT|COMP-SYS|N/A|Symantec AntiVirus/16;Info;Virus definitions are current.
2009 11 04 09:00:12|SysEvent.Evt – EVT|COMP-SYS|N/A|Service Control Manager/7036;Info;LiveUpdate,stopped

Very interesting that many of these events seem to occur during some type of AV updating or scanning activity.  Although really just an interesting side note, this does show that AV can only prevent what it is programmed to understand.  The following events do not fall into that category.

2009 11 04 09:19:09|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18|Change Time (ctime)
2009 11 04 09:19:09|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18|Modified Time (mtime)
2009 11 04 09:19:09|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18\d42cc0c3858a58db2db37658219e6400_dbcab107-5342-4908-9e95-0aba2546f18b|Accessed Time (atime)
2009 11 04 09:19:09|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18\d42cc0c3858a58db2db37658219e6400_dbcab107-5342-4908-9e95-0aba2546f18b|Change Time (ctime)
2009 11 04 09:19:09|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S-1-5-18\d42cc0c3858a58db2db37658219e6400_dbcab107-5342-4908-9e95-0aba2546f18b|Created Time (crtime)

These files appear to be associated with Microsoft Cryptographic Service Providers.  I am still researching what this actually implies.  Please post a comment if you can provide some insight.

2009 11 04 09:21:00|SysEvent.Evt – EVT|COMP-SYS|S-1-5-18|Service Control Manager/7035;Info;UpsGSx,start
2009 11 04 09:21:00|SysEvent.Evt – EVT|COMP-SYS|N/A|Service Control Manager/7036;Info;UpsGSx,running
2009 11 04 09:21:00|SysEvent.Evt – EVT|COMP-SYS|S-1-5-18|Service Control Manager/7035;Info;UpsGSx,stop

This service is a malicious backdoor that has been related to Hydraq. Notice that new services do get logged to Windows Event Logs but only if your systems are configured to log.  But why did this service start?

2009 11 04 09:21:00|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\Tasks|Change Time (ctime)
2009 11 04 09:21:00|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\Tasks|Modified Time (mtime)

Ah, a modification to the Scheduled Tasks folder.  This could be an indication that a job was scheduled to run.

2009 11 04 09:21:00|Registry Hive: software|COMP-SYS|0|$$$PROTO.HIV/Microsoft/SchedulingAgent
2009 11 04 09:21:00|Registry Hive: system|COMP-SYS|0|$$$PROTO.HIV/ControlSet001/Enum/Root/LEGACY_UPSGSX/0000
2009 11 04 09:21:00|Registry Hive: system|COMP-SYS|0|$$$PROTO.HIV/ControlSet002/Enum/Root/LEGACY_UPSGSX/0000

More activity associated with the UPSxxx backdoor service starting.

2009 11 04 09:21:00|Task Log|COMP-SYS|”At1.job” (a.exe)    Started 11/4/2009 5:21:00 PM|0
2009 11 04 09:21:00|Task Log|COMP-SYS|”At1.job” (a.exe)    Finished 11/4/2009 5:21:00 PM    Result: The task completed with an exit code of (0).|0

Well, now, what do we have here?  A scheduled task running a strange executable.  And, at the exact same time that the UPSxxx backdoor service started.  Nobody said that timeline information will be presented down to the millisecond.  Obviously this action occurred before some of the other events.  Had the conversion from local time to UTC been off this data might have been lost and not associated with these events.

2009 11 04 09:31:58|SysEvent.Evt – EVT|COMP-SYS|N/A|Tcpip/4226;Warn;

Once, Harlan Carvey recommended that I get a subscription to EventID.net.  Here is where that subscription pays off.  The description for Event ID 4226 reads “TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts.”  Well, now, it seems that there is a large number of outgoing connection attempts.  Additional comments from other users of EventID.net provide indications that this type of activity can be linked to malware.  And to think, this was alerted in the Windows Event Logs no less.  Did I mention that these should be turned on?  Starting to seem very useful right about now.

2009 11 04 09:35:30|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\snmpapi.dll|Accessed Time (atime)
2009 11 04 09:35:30|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\inetmib1.dll|Accessed Time (atime)
2009 11 04 09:35:30|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\netstat.exe|Accessed Time (atime)
2009 11 04 09:36:53|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\wbem\wbemperf.dll|Accessed Time (atime)
2009 11 04 09:36:53|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\systeminfo.exe|Accessed Time (atime)
2009 11 04 09:36:55|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\wbem\stdprov.dll|Accessed Time (atime)
2009 11 04 09:41:17|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\tasklist.exe|Accessed Time (atime)
2009 11 04 09:43:27|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\WINDOWS\system32\nbtstat.exe|Accessed Time (atime)
2009 11 04 09:46:58|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\RECYCLER|Change Time (ctime)
2009 11 04 09:46:58|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\RECYCLER|Modified Time (mtime)

Okay, here is the hot and juicy stuff.  Wow, look at those Access times.  Access times on executables are indicative of the execution of these programs.  “Netstat”, “Systeminfo”, “tasklist”, and “nbtstat”.  All one after another? Very interesting.  The accessed DLLs also show us that other programs might have been run around this time.  SNMP?  Simple Network Management Protocol – a little network management anyone? WBEM? Web-Based Enterprise Management.  Definitely more reconnaissance behavior.

I would also like to point out that this activity appears to have occurred approximately ten minutes after the backdoor was placed on this system using the scheduled task.  So, following logic, this system was compromised from another system within the network.  The attacker completed the working on that first system (possibly similar reconnaissance efforts) and then connected to this system via the backdoor.  Why the backdoor?  Well, logging is turned on.  There is no network logon event.  This could very well mean that the user’s actual credentials have not been compromised, YET.  Or, this could mean the attacker did not want to generate a logon event, or it could mean that he required some functionality provided by the backdoor.  We are starting to read into this a little too much at this point.  But our initial thoughts, compromised from another system on the internal network and performing reconnaissance steps, are still sound.

2009 11 04 10:12:46|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP34\A0034337.properties|Accessed Time (atime)
2009 11 04 10:12:46|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP34\A0034337.properties|Change Time (ctime)
2009 11 04 10:12:46|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP34\A0034337.properties|Modified Time (mtime)
2009 11 04 10:13:10|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\Administrator\Local Settings\Temp\vmware-user\vmware-3856-mks-user-476.log|Accessed Time (atime)
2009 11 04 10:13:10|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\C\Documents and Settings\Administrator\Local Settings\Temp\vmware-user\vmware-3856-mks-user-476.log|Change Time (ctime)
2009 11 04 10:13:35|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\D\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP33|Created Time (crtime)
2009 11 04 10:13:35|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\D\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP33\change.log.1|Created Time (crtime)
2009 11 04 10:13:37|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\D\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP34\A0034288.dll|Change Time (ctime)
2009 11 04 10:13:37|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\D\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP34\A0034288.dll|Created Time (crtime)
2009 11 04 10:13:37|EnCase File TLN|COMP-SYS|COMP-SYS\Disk Image\D\System Volume Information\_restore{01E266C2-86F5-40B2-9145-B4252FFF29C3}\RP34\A0034287.dll|Change Time (ctime)

Ah, the System Restore Point.  This simple occurrence could be very helpful indeed.  It is quite possible that the Upsxxx backdoor was captured and stored in this System Restore Point.  This is very useful information especially if the malware has rolled over to a new version.  If your security team is looking for a different version of the backdoor, systems compromised with the version captured in this restore point may still be beaconing or allowing access to your environment.  Time to dive into these System Restore Points and see what they yield.

Hopefully you have found this helpful.

Go forth and do good things,

Don C. Weber

---

Help support my training and travel to security conferences. Get your SANS Training and GIAC Certifications through the Security Ripcord.

---

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.