Detecting malware beacons using Splunk

Note: Although this was created some time back (sorry for sharing this so late), there’re improvements to be made still.  Discussions are always welcomed.

When responding to an enterprise network compromise, one big question (and source of pressure) is that network IOCs need to be determined quickly. While this information would usually come from the malwares/tools used in the compromise, the fact that the surfacing of network IOCs and triaging being done in parallel presents a Catch-22 situation: How do we find machines and malware without network IOCs available? How do we get network IOCs without analyzing any machines/malware suspects?

Sending messages temporarily via SMS instead of iMessage

One of the “new” things that you will encounter when changing to an iPhone (or simply by upgrading to iOS 5 and above) is the addition of iMessage. This allows you to send messages ala WhatsApp style over the network as long as you have an internet connection, be it from your iPhone, iPod Touch or iPad.

As nice as iMessage is to use, there would be times when you need to send SMSes instead to another iPhone: be it when the recipient has turned off the data connection or is in a place with an unreliable connection. And no, going to Settings to turn off your data connection to force sending as SMS doesn’t cut it either.

The solution to this is simple, seems that Apple had already thought this one out. [Edit: Sadly, this apparently does not work in iOS 5.] When the message is being sent, or anytime before the message gets the “Delivered” status, simply press-hold on the message being sent to access the alternate menu and select “Send as Text Message”. That message will then change from blue (for iMessage) to green (for SMS) as it sends the message as an SMS instead.

Simple solution: press-hold on the message to access the menu where you can “Send as Text Message”

This works out fine as there is no need to (re)send the message as an SMS if the message has already been delivered via iMessage (the “Send as Text Message” option is made unavailable for messages that are already delivered). Also, it appears that it tries to send the message automatically via SMS should the iMessage delivery take too long or fail for some reason. Nice 🙂

HTH.

Making DD even more awesome

Deputy Director? No…the Unix dd command!

The dd command is one of the most versatile and powerful tools you will find in a Linux box, it is an awesome command! Disk wiping is only one of the more common uses for it. There’re some other tricks that I use dd for, but those will have to be left for another post…

You may have noticed that there’s a tip on monitoring the current status of the dd command right at the end of the --help output:

$ dd --help

{...}
Sending a USR1 signal to a running `dd' process makes it
print I/O statistics to standard error and then resume copying.

  $ dd if=/dev/zero of=/dev/null& pid=$!
  $ kill -USR1 $pid; sleep 1; kill $pid
  18335302+0 records in
  18335302+0 records out
  9387674624 bytes (9.4 GB) copied, 34.6279 seconds, 271 MB/s
{...}

That works as stated, but what if you want to get a continuous status update on the state of the dd command for long tasks such as wiping a hard drive? Well, you use a loop to do that.

As for keeping the loop running for only as long as the dd process is alive and working, I use the -a test to check that the cmdline file for that process id exists. When the process dies, the proc folder is deleted shortly after, and the cmdline file ceases to exist. That will cause the while loop to exit too. No more flooding the screen with useless output!

$ sudo dd if=/dev/zero of=/dev/sdc & pid=$!
$ sudo while [ -a /proc/$pid/cmdline ]; do echo; date; sudo kill -USR1 $pid; sleep 1; done

Thu Sep  6 02:00:12 SGT 2012
63637313+0 records in
63637313+0 records out
32582304256 bytes (33 GB) copied, 6814.37 s, 4.8 MB/s

Thu Sep  6 02:00:14 SGT 2012
63643513+0 records in
63643513+0 records out
32585478656 bytes (33 GB) copied, 6815.34 s, 4.8 MB/s

Thu Sep  6 02:00:15 SGT 2012
63649217+0 records in
63649217+0 records out
32588399104 bytes (33 GB) copied, 6816.46 s, 4.8 MB/s

Thu Sep  6 02:00:16 SGT 2012
63657193+0 records in
63657193+0 records out
32592482816 bytes (33 GB) copied, 6817.42 s, 4.8 MB/s

HTH.