Thursday, May 7, 2009
Saturday, April 18, 2009
random text from CIPAV PDF
3 b o r t e d that residential address 6133 Winhwood Loop SE, Olympia, WA, 98515
received Comcast Internet services for the following subscriber:
14
Sam Spiering
:IS
6133 W i w o o d Loop SE, Lacey, WA 98513
Telephdne (360) 455-0569
17
Dynamically Assigned Active Account
Account Number: 8498380070269681
19
On June 4.2007. Cioogle provided subscriber, registration. and IF Address
25
log history for e-mail address "douebriggS11236email.corn"with the following results:
26
E a l d (user deleted account)
nbe
27 Status:
Setvims: Talk, Search History, Gmail
28
*
On June 7,2007, a request to MySpace for subscriber and IP
b.
)
ddress l&s for Myspace user "Timberlinebombinfo"provided the foilowing results:
User I :
D 199219316
Fs Name:
it
r Doug
last Name: , Briggs
Male
Gender; .
Dt of B r h
ae i t : 12110J1992
Age; 14
"
US
couq:
Law
City:
stal Code: 985003
Western Australia
Region:
Email'Address:' tirnberljne.sucksB~mai1
.corn
User Name: timberlinebambinfo
Sign up I Address:
P 80.76.80.103
Sign up Date: Juae 7,2007 7:49PM
NIA
Delete Date:
June 7,20077:49:32:247 PM I Address 80.76.80.103
P
Login Date
:page 76:
15. The C P A V will be deployed through an electronic messaging program
,
conaolled by the FBI. The computers sending and receiving the
CIPVA will be machines controlled by the FBI. The electtonic message deploying the
CIPAV will be directed to the administrator(s) of the "Timberlinebambinfo"
Electronic messaging accouuts commonly require a unique user
a).
same and password.
Once the CIPAV is successfully deployed, it will conduct a one-
b.
)
time search of the activat'ing computer and capture the information
desctibed in paragraph seven.
The captured information will be forwarded to a computer
c).
conmlled by the FBI located within the Eastern Disuicc of
,
Virginia.
After the onetime search, the CIPAV will function asa pen register
d).
device anxl record the muting and destination addressing information
for electronic communications originating f o the activahg
rm
computer.
The pen register will recod PB address, dates, m d times of the
e).
electronic comwnicatiom, but not the aoutents of such
ccmmunieatioas or the contents contained on the computer, and
address data to a computer cantroned by bhye
U'mard the
FBI,P r p d o d of (60) days.
w
received Comcast Internet services for the following subscriber:
14
Sam Spiering
:IS
6133 W i w o o d Loop SE, Lacey, WA 98513
Telephdne (360) 455-0569
17
Dynamically Assigned Active Account
Account Number: 8498380070269681
19
On June 4.2007. Cioogle provided subscriber, registration. and IF Address
25
log history for e-mail address "douebriggS11236email.corn"with the following results:
26
E a l d (user deleted account)
nbe
27 Status:
Setvims: Talk, Search History, Gmail
28
*
On June 7,2007, a request to MySpace for subscriber and IP
b.
)
ddress l&s for Myspace user "Timberlinebombinfo"provided the foilowing results:
User I :
D 199219316
Fs Name:
it
r Doug
last Name: , Briggs
Male
Gender; .
Dt of B r h
ae i t : 12110J1992
Age; 14
"
US
couq:
Law
City:
stal Code: 985003
Western Australia
Region:
Email'Address:' tirnberljne.sucksB~mai1
.corn
User Name: timberlinebambinfo
Sign up I Address:
P 80.76.80.103
Sign up Date: Juae 7,2007 7:49PM
NIA
Delete Date:
June 7,20077:49:32:247 PM I Address 80.76.80.103
P
Login Date
:page 76:
15. The C P A V will be deployed through an electronic messaging program
,
conaolled by the FBI. The computers sending and receiving the
CIPVA will be machines controlled by the FBI. The electtonic message deploying the
CIPAV will be directed to the administrator(s) of the "Timberlinebambinfo"
Electronic messaging accouuts commonly require a unique user
a).
same and password.
Once the CIPAV is successfully deployed, it will conduct a one-
b.
)
time search of the activat'ing computer and capture the information
desctibed in paragraph seven.
The captured information will be forwarded to a computer
c).
conmlled by the FBI located within the Eastern Disuicc of
,
Virginia.
After the onetime search, the CIPAV will function asa pen register
d).
device anxl record the muting and destination addressing information
for electronic communications originating f o the activahg
rm
computer.
The pen register will recod PB address, dates, m d times of the
e).
electronic comwnicatiom, but not the aoutents of such
ccmmunieatioas or the contents contained on the computer, and
address data to a computer cantroned by bhye
U'mard the
FBI,P r p d o d of (60) days.
w
more info released on FBI's home brewed malware, CIPAV
Recently, the Freedom of Information Act was invoked by the EFF, CNET and Wired to declassify documents relating to the FBI's home brewed malware, CIPAV.
The newly released PDF weighs in at a healthy 150 pages, with info on various requests and cases where CIPAV was used.
At this time it does not seem to be public knowledge exactly what the software does and more importantly, how it gets on the "victims" machine.
After a 2007 affidavit some of the security community's finest had put together a pretty good profile of what the software was likely doing:
More clues are likely to emerge from the recently released documents, but my guess is that it will still remain a guessing game as to what exactly the software does.
Regardless of what information the malware collects, the new documents shed some interesting light on the complicated and precise environment that the malware is supposed to run in on one particular case. On page 78 of the PDF it is noted that the software should only be deployed between the hours of 6AM and 10PM PST. Once deployed, messages can read coming from the infected machine at any time. Interesting for sure, perhaps even a bit strange. My guess is that the deployment hours correlate to previous bomb threats, and thus the regulated window, but thats purely speculation.
In the following page of the PDF, 79 it is noted that if the CIPAV does not activate on the victims machine, they will attempt to deploy and activate until successful. This with in the 10 day allotted window for deployment. This seems to be a key factor in understanding how this malware works. An application to collect the above mentioned data could be written in any number of languages and hidden on the machine in an overwhelming number of ways. When you consider the infection from the FBI's point of view, it would probably make the most sense to send a windows based app first, but maybe its all universal now anway?. First thing it does after activation is open up an SSL connection and phone home, IP, MAC, last URL and so on... Now, if activation does not occur right away, they act quickly while the Myspace vunerablilty is still active and send over a totally different app, wait for phone home and repeat.
The Wired article does a great job of assessing what vulnerability was used to deliver the malware and as usually spend my time on the recieving end, I don't have any thing interesting to add there.
Lots more interesting info coming out of that PDF. I'm looking forward to the next fews days. Up next I think I'll get into how we might be able to get our hands on one of these CIPAV files.
The newly released PDF weighs in at a healthy 150 pages, with info on various requests and cases where CIPAV was used.
At this time it does not seem to be public knowledge exactly what the software does and more importantly, how it gets on the "victims" machine.
After a 2007 affidavit some of the security community's finest had put together a pretty good profile of what the software was likely doing:
The full capabilities of the FBI's "computer and internet protocol address verifier" are closely guarded secrets, but here's some of the data the malware collects from a computer immediately after infiltrating it, according to a bureau affidavit acquired by Wired News.
- IP address
- MAC address of ethernet cards
- A list of open TCP and UDP ports
- A list of running programs
- The operating system type, version and serial number
- The default internet browser and version
- The registered user of the operating system, and registered company name, if any
- The current logged-in user name
- The last visited URL
More clues are likely to emerge from the recently released documents, but my guess is that it will still remain a guessing game as to what exactly the software does.
Regardless of what information the malware collects, the new documents shed some interesting light on the complicated and precise environment that the malware is supposed to run in on one particular case. On page 78 of the PDF it is noted that the software should only be deployed between the hours of 6AM and 10PM PST. Once deployed, messages can read coming from the infected machine at any time. Interesting for sure, perhaps even a bit strange. My guess is that the deployment hours correlate to previous bomb threats, and thus the regulated window, but thats purely speculation.
In the following page of the PDF, 79 it is noted that if the CIPAV does not activate on the victims machine, they will attempt to deploy and activate until successful. This with in the 10 day allotted window for deployment. This seems to be a key factor in understanding how this malware works. An application to collect the above mentioned data could be written in any number of languages and hidden on the machine in an overwhelming number of ways. When you consider the infection from the FBI's point of view, it would probably make the most sense to send a windows based app first, but maybe its all universal now anway?. First thing it does after activation is open up an SSL connection and phone home, IP, MAC, last URL and so on... Now, if activation does not occur right away, they act quickly while the Myspace vunerablilty is still active and send over a totally different app, wait for phone home and repeat.
The Wired article does a great job of assessing what vulnerability was used to deliver the malware and as usually spend my time on the recieving end, I don't have any thing interesting to add there.
Lots more interesting info coming out of that PDF. I'm looking forward to the next fews days. Up next I think I'll get into how we might be able to get our hands on one of these CIPAV files.
Tuesday, April 14, 2009
Malware String Analysis Part 1 - Getting the Strings
String analysis can be very useful when it comes to researching and gathering information on suspicious or unknown files. There is all different kinds of information that can be gathered from the strings of a file, and there are of course any number of ways to obtain and process this information. In this "part 1" i'm going to go over some of the more common ways to extract the strings from a file.
If you are doing your research on a windows machine, one of the easiest ways to extract the strings of a file is to use the Sysinternals tool Strings. I like to run application against files with a batch file in the "send to" folder. This allows me to simply right click on the file in question and click "send to", then, Strings". As instructed by my batch file, the app pushes the extracted strings into a txt file for me. You can set your research box up in a similar fashion by doing the following:
click start, run, the type "sendto"
This will open the sendto folder. Right click, "new", "text document". Here's what I use, but you could of course modify as you like:
As stated on the man page on in the link above, there are various options you can use with the Strings command:
Using Strings
Using the above method you should be able to extract the strings of a file pretty quickly with out much of a hassle.
If you want to do the same on Linux, chances are that you already have the necessary tool. If you type "strings" at the command prompt you know pretty quickly. In order to get this working the same as the Sysinternals tool you will need to add some extra arguments as its defualt output is pretty raw. I'm not entierly sure what those are as I usually just rip the strings off my windows research box, but if anyone know the equivilant command please post it up.
Really basic stuff, but there is all kinds of interesting things that can come from those strings. Next time we'll looks at some output files and a cool tool called Yara, that helps parse the strings all quick like.
If you are doing your research on a windows machine, one of the easiest ways to extract the strings of a file is to use the Sysinternals tool Strings. I like to run application against files with a batch file in the "send to" folder. This allows me to simply right click on the file in question and click "send to", then, Strings". As instructed by my batch file, the app pushes the extracted strings into a txt file for me. You can set your research box up in a similar fashion by doing the following:
click start, run, the type "sendto"
This will open the sendto folder. Right click, "new", "text document". Here's what I use, but you could of course modify as you like:
strings -a %1 >"C:\strings.txt"Make sure you save the file with the extension .bat, and not .txt. Strings.bat is a pretty good name.
"C:\strings.txt"
exit
As stated on the man page on in the link above, there are various options you can use with the Strings command:
Using Strings
Usage: strings.exe [-a] [-b bytes] [-n length] [-o] [-q] [-s] [-u]
Strings takes wild-card expressions for file names, and additional command line parameters are defined as follows:
| -s | Recurse subdirectories. |
| -o | Print offset in file string is located. |
| -a | Scan for ASCII only. |
| -u | Scan for UNICODE only. |
| -b bytes | Bytes of file to scan. |
| -n X | Strings must be a minimum of X characters in length. |
To search one or more files for the presence of a particular string using strings use a command like this:
strings * | findstr /i TextToSearchFor
Using the above method you should be able to extract the strings of a file pretty quickly with out much of a hassle.
If you want to do the same on Linux, chances are that you already have the necessary tool. If you type "strings" at the command prompt you know pretty quickly. In order to get this working the same as the Sysinternals tool you will need to add some extra arguments as its defualt output is pretty raw. I'm not entierly sure what those are as I usually just rip the strings off my windows research box, but if anyone know the equivilant command please post it up.
Really basic stuff, but there is all kinds of interesting things that can come from those strings. Next time we'll looks at some output files and a cool tool called Yara, that helps parse the strings all quick like.
Thursday, January 8, 2009
Virtual box w/Ubuntu 8.10 x64
Started here:http://www.howtoforge.com/installing-virtualbox-2.0.0-on-ubuntu-8.10-desktop
Ok, well that was so easy and worked exactly as expected that there is no need to write anything up. awesome.
Ok, well that was so easy and worked exactly as expected that there is no need to write anything up. awesome.
Thursday, November 27, 2008
TDSS Rootkit Removal
I got a call the other day from a friend asking if I could take a look at his computer. Based on what he described, it sounded like a pretty standard combo infection of Anti-Virus 2009 and FakeAlert. He gave me the box, and a few days later I took a look.
The box would only boot into Windows successfully about one out of every 4 times. Once into windows, I found Antivirus 2009 and FakeAlert. As always, I tried the easiest things first, install Spy Sweeper and or Hijack This. Neither would install normally, so I changed the HJT folder name and .exe name, still would not run. Although Spy Sweeper would install, upon reboot it would say that the install was corrupt or something. At this point I should have realized there was a Rootkit.
I booted the box into a Slax live CD and went about removing AntiVirus2009 manually. Slax doesn't mount NTFS drives with write privileges by default, in order to accomplish this I ran the following commands:
umount /dev/hda2
ntfsmount /dev/hda2 /mnt/hda2
Now, had I know there was a rootkit and know a little about it TDSS, I could have probably killed it this time around. As I didn't, the process ended up taking quite a bit longer. Instead of simply removing Antivirus2009, I should have tried something like:
cd /mnt/hda2/windows/system32/drivers
ls tdss*
rm tdss*
cd ..
ls
and delete all .exe and .dll files with dates of 2009 on them (this may not work in a few months!)
Since I didn't realize there was a rootkit I simply removed Antivirus 2009 and rebooted.
Once I booted back into Windows I saw that fakealert was still there (and re-installing Antivirus2009) I decided to run rootkit revealer and see what it came up with. Sure enough there were a few entries for TDSSserv.sys and TDSSdata, and then two errors where it said it couldn't mount the the C and D driver. Did a little research on TDSS and realized that the box was most definitely rootkitted.
I played with the registry through regedit, but guess what, the only TDSS entries that were showing up were legacy data that would not stop the rootkit. No surprise. I searched the intewebs, read a variety of posts, grabbed a bunch of tools, Gmer, Icesword, and a bunch of others that I didn't end up using. I also created a UBCD4WIN boot disk based on this http://www.s-t-f-u.com/2008/10/29/rootkit-tdsssys-sucks-worse-than-a-2-dollar-whore-remove-it/ excellent post.
Now since I removed antivirus 2009 manually through Slax, I had created some discrepancies or problems with the disk. It still booted, into windows, but would not run a scheduled CHKDSK and I could no longer mount the volume in Slax because it gave some error, saying the volume was dirty and needed a chkdsk run.
I guess I really didnt need the UBCD4Win, as after like 15 mins it still hadn't booted, and because I'm impatient I just killed it and and used it to boot into the recovery console, but still, seems like something I will most definitely be using in the future.
After booting into the recovery console, I did what I should have done though Slax the first time around, and went to system32 removed all .exe's and .dll's with 2009 timestamps on them (at the time of this writing, that worked great, but probably wont soon as its almost 2009), and then into system32/ drivers got rid of all the TdssXXXX.sys files (where X= equals random characters). There were also some .ini files with 2009 dates on them that I probably could have removed, but didn't.
Rebooted into windows, to find that fakealert was still there. Opened Icesword (which is a fuking cool app) and killed the fakealert .exe manually (bratsk.exe or something). Since I couldn't find a way to search the registry though Icesword I just used regedit to search for "tdss" then navigated to those locations in IceSword (it takes care of permissions so deleting keys is far easier than in regedit) and delete the fuk out of anything tdss. The most interesting by far was the disallow section of TDSSDATA (I think that was it). It contained all the hooks that kept SS, Gmer, and all those other apps from running. I was able delete all TDSS entries. Rebooted.
Still had Fakealert. Searched the registry for TDSS. TDSSDATA was still there, but it looked like it hadn't fully set up as the keys were not there. Deleted it. At this point I was able to successfully install my prefered malware removal app (and inserted newest def set manually cause I work for them) and when I rebooted, the CHKDSK that I had scheduled many boot cycles actually kicked off.
The malware removal app install went through this time and I ran a full scan. Still waiting to see what all it found and removed, but at this point i'm pretty confident that the TDSS rootkit is dead. Big ups to the TDSS guy though, thats a pretty nice rootkit, and I know for a fact that you have at least one major malware vendor re-working their engine to accommodate removal (even if you hit after the engine was installed).
So, for the first time after getting the box, i feel safe connecting it up to the intewebs to get some likely much needed updates which is my guess where this came from.
Also, I heard that Microsoft released an update this week that removed over 1 million copies of rogue Antivirus apps? very interesting.
The box would only boot into Windows successfully about one out of every 4 times. Once into windows, I found Antivirus 2009 and FakeAlert. As always, I tried the easiest things first, install Spy Sweeper and or Hijack This. Neither would install normally, so I changed the HJT folder name and .exe name, still would not run. Although Spy Sweeper would install, upon reboot it would say that the install was corrupt or something. At this point I should have realized there was a Rootkit.
I booted the box into a Slax live CD and went about removing AntiVirus2009 manually. Slax doesn't mount NTFS drives with write privileges by default, in order to accomplish this I ran the following commands:
umount /dev/hda2
ntfsmount /dev/hda2 /mnt/hda2
Now, had I know there was a rootkit and know a little about it TDSS, I could have probably killed it this time around. As I didn't, the process ended up taking quite a bit longer. Instead of simply removing Antivirus2009, I should have tried something like:
cd /mnt/hda2/windows/system32/drivers
ls tdss*
rm tdss*
cd ..
ls
and delete all .exe and .dll files with dates of 2009 on them (this may not work in a few months!)
Since I didn't realize there was a rootkit I simply removed Antivirus 2009 and rebooted.
Once I booted back into Windows I saw that fakealert was still there (and re-installing Antivirus2009) I decided to run rootkit revealer and see what it came up with. Sure enough there were a few entries for TDSSserv.sys and TDSSdata, and then two errors where it said it couldn't mount the the C and D driver. Did a little research on TDSS and realized that the box was most definitely rootkitted.
I played with the registry through regedit, but guess what, the only TDSS entries that were showing up were legacy data that would not stop the rootkit. No surprise. I searched the intewebs, read a variety of posts, grabbed a bunch of tools, Gmer, Icesword, and a bunch of others that I didn't end up using. I also created a UBCD4WIN boot disk based on this http://www.s-t-f-u.com/2008/10/29/rootkit-tdsssys-sucks-worse-than-a-2-dollar-whore-remove-it/ excellent post.
Now since I removed antivirus 2009 manually through Slax, I had created some discrepancies or problems with the disk. It still booted, into windows, but would not run a scheduled CHKDSK and I could no longer mount the volume in Slax because it gave some error, saying the volume was dirty and needed a chkdsk run.
I guess I really didnt need the UBCD4Win, as after like 15 mins it still hadn't booted, and because I'm impatient I just killed it and and used it to boot into the recovery console, but still, seems like something I will most definitely be using in the future.
After booting into the recovery console, I did what I should have done though Slax the first time around, and went to system32 removed all .exe's and .dll's with 2009 timestamps on them (at the time of this writing, that worked great, but probably wont soon as its almost 2009), and then into system32/ drivers got rid of all the TdssXXXX.sys files (where X= equals random characters). There were also some .ini files with 2009 dates on them that I probably could have removed, but didn't.
Rebooted into windows, to find that fakealert was still there. Opened Icesword (which is a fuking cool app) and killed the fakealert .exe manually (bratsk.exe or something). Since I couldn't find a way to search the registry though Icesword I just used regedit to search for "tdss" then navigated to those locations in IceSword (it takes care of permissions so deleting keys is far easier than in regedit) and delete the fuk out of anything tdss. The most interesting by far was the disallow section of TDSSDATA (I think that was it). It contained all the hooks that kept SS, Gmer, and all those other apps from running. I was able delete all TDSS entries. Rebooted.
Still had Fakealert. Searched the registry for TDSS. TDSSDATA was still there, but it looked like it hadn't fully set up as the keys were not there. Deleted it. At this point I was able to successfully install my prefered malware removal app (and inserted newest def set manually cause I work for them) and when I rebooted, the CHKDSK that I had scheduled many boot cycles actually kicked off.
The malware removal app install went through this time and I ran a full scan. Still waiting to see what all it found and removed, but at this point i'm pretty confident that the TDSS rootkit is dead. Big ups to the TDSS guy though, thats a pretty nice rootkit, and I know for a fact that you have at least one major malware vendor re-working their engine to accommodate removal (even if you hit after the engine was installed).
So, for the first time after getting the box, i feel safe connecting it up to the intewebs to get some likely much needed updates which is my guess where this came from.
Also, I heard that Microsoft released an update this week that removed over 1 million copies of rogue Antivirus apps? very interesting.
Tuesday, November 11, 2008
Enabling VNC in Ubuntu Intrepid
If you want to use the VNC viewer client in Ubuntu Intrepid but its greyed out, simply run:
sudo apt-get install xtightvncviewer
and you should be all set.
Subscribe to:
Posts (Atom)
