Six Ways a Russian Hacker Attacked My Website
Until today, the "russian hacker" seemed like a piece of news-hyped fantasy. It turns out, that just isn't the case. They're real. They've attacked me, and they can attack you.
I want to be very clear at the head of this, this article features REAL links to this russian hacker's files and everything I was able to trace back to him. I did not candy-coat anything at all. If you're uncomfortable clicking those links, don't. If you choose to click the links, use a VPN, avoid running his files on your computer, and be safe. I'm not responsible for anything that happens if you interact with his stuff.
As you may have guessed after seeing my intro image, the hacker attacked me with injections through an input on my webpage. Put simply, he typed code into a search bar to see if he could get my server to do what he wanted it to do instead of what I was telling it to do. Had I not been properly sanitizing the data I was collecting from this input, he would have been successful.
Now, I'm not going to dance around what happened or try to tell you anything in an abstract way. I think it's important to know what hackers are trying these days so we know how to best protect ourselves. So, I've decided to include an actual screenshot of the "searches" this hacker typed into my search bar here.
You can ignore the 0's at the end of each line and the "groupSites0" at the beginning of each line. Those are search filters that have nothing to do with the malicious aspect of each of these searches. Let's get to the meat of these attack methods.
Attack #1: "etc/group" file searching
"etc/group" files are something I just learned about, and that's part of the reason this article is listed as a "discussion" piece. I'll tell you what I know, and please let me know in the comments if you have more to offer. To my knowledge, this hacker was assuming I use a Linix/UNIX operating system for my server. With Linix/UNIX operating systems, etc/group files contain a list of all users that have permissions for the server, which would be a great thing to have if you were trying to pretend to be me and gain access to my backend. The "../" here just means that he's trying to access parent directories within my backend's filesystem. That's not hugely relevant to the attack method here.
Attack #2: FTP file injection
This is by far my favorite attack that the hacker used. He was trying to upload a file to my server from his own, but he wasn't counting on me recording his searches for database backup purposes. By trying to connect his FTP to my server, he gave me access to his files. You see that URL in line 671 above? That's his real FTP, and you can visit it at ftp://ref:ref@dahli.rosinter.ru:21, though I'll save you the trouble if you are understandably wary. I'm including a screenshot of his files available at that link here.
He has a lot of files about a company called Qlik, and his FTP's parent domain either is or is pretending to be a Russian food company. That test.txt file you see there is what he was trying to upload to my server. What's in it? Nothing actually harmful, just a bit ominous.
Attack #3: "phpinfo" probing
phpinfo basically tells you everything about my PHP settings. It'll tell you what version of PHP I'm operating on, how long I let scripts run for before automatically terminating them, what environment variables I'm trying to hide from prying eyes, and a ton of other juicy goodies. But really, what the hacker is looking for here is just to see whether he can get any info out of me at all. Before trying to figure out what my thousands of users' passwords are, it's easier to ask for phpinfo to see if I'm even vulnerable to an attack in the first place.
Attack #4: Base64 injection
This one's another phpinfo probe in disguise. Base64 strings are usually used as the text-formatted version of images, but this one is the text format of a PHP file. And when you decode data:;base64,PD9waHAgcGhwaW5mbygpOyA/Pg==, guess command you get? That's right, <?php phpinfo(); ?>. Feel free to try it yourself here.
Attack #5: Further "etc/group" file searching
The attacker had no luck with his first "etc/group" file search, so he figured it'd be worth one more go in a different directory. No luck there either, but nice try.
Attack #6: w;w;w
I actually don't get this one. It almost seems like he's trying to set write permissions for himself? I'd love if the community could chip in in the comment section to let me know what this could be.
The Scariest Part...
I timestamp every search that goes into my searchbar. Every single one of these six searches were executed within a timespan of 30 seconds (from 6:36:32 AM through 6:36:59 AM). That means this person has this whole process automated. He goes from site to site, poking around to find any holes that he can exploit, and when he finds one, he knows plenty of ways to take advantage and get what he wants. And he does it all through VPN connections that don't trace back to him. If you're interested, here are the IPs he used:
- 82.150.140.160 (not blacklisted, in Amsterdam, Netherlands)
- 79.170.40.224 (blacklisted, in London, UK)
- 79.170.40.225 (heavily blacklisted, in London, UK)
Please use this as an opportunity to learn and take caution with your development. Not everyone plays by the rules.
--
Top comments (30)
1) the FTP might not be his. It was pretty easy and common in the past to search for anonymous writeable FTP servers, FTP servers with leaked credentials (accidentally left in source code on github or elsewhere) and to misuse them as an attack vector.
2) the w;w;w might be an attempt to call a "w" command on linux which displays list of active users. Like here:
user@host:~# w
20:19:41 up 218 days, 13:22, 1 user, load average: 0.09, 0.08, 0.02
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/1 111.222.333.444- 20:18 5.00s 0.04s 14.70s mosh-server new -c 256 -s -l LANG=en_US.UTF-8 -l LC_CTYPE=UTF-8 -l LC_ALL=en_US.UTF-8
I've had similar incidents where someone whos IP address indicated they were from Russia tried various of these tactics to access my employers website via one of the CMS pages. They automate it because automation is easy, and they can try and gain access whilst they sleep. Some of them have so many things to try, it effectively becomes a DoS attack.
Fortunately I have a Web Application Firewall (WAF) in place, and they are able to identify countries by IP (to some limited degree). As we don't do business with Russia for legislative purposes, I was able to block the entire country. It's not something I particularly wanted to do, but they changed IP address once I blocked the one they were coming from.
It's always going to be game of cat-and-mouse, with people wanting to control as many servers as possible to instigate DDoS attacks, mine cryptocurrency, or steal data
Fortunately my security was tight, so they all failed- but it is very disquieting that people actually dedicate themselves to this type of thing. Thanks for the follow by the way :)
What do you recommend such as a web security steps or configurations that you recommend to keep my website safe? Is coded in php.
There are a lot of things you can do. Some basic ones are:
Super helpfull!! Thanks ❤😊
Btw I didn't know that sha512 exists 😂😂
<script>alert("haha");</script>
It usually is a good idea to start with a simple payload like "hack_test". Proving you have remote file upload for a less malicious file is a good way to confirm the vulnerability exists before properly exploiting it and uploading say a reverse shell.
As someone who's always been fascinated by cyber-security, but doesn't have any idea of where to start or what to learn, this was fascinating. I liked the fact you showed everything and got straight to the point. These hackers are quite scary when you think about how many potential websites they've compromised.
ну да, с русскими надо осторожней)
Nice article... I can see that more attack are always on PHP websites that's why most developers are now jumping to Go and python...
The truth is no website isn't prone to attacks. It does not depend on the language you use...
It depends on how crafty you are and how to mitigates attacks just like nastyox1 did.
This days I will share on GitHub the advanced security class I designed for people to use... It takes care of $_POST and $_GET including providing encryptions and preventing XSS too... And automatically block suspicious ip
Hey, thanks for sharing all the details of the attack, even though he didn't use any especially clever, still good to be reminded of what could go wrong.
Being Russian myself, I don't think his nationality has much to do with the contents of your post though ;-)
This post is so nice, thank's for sharing the whole process, useful! And btw bravo for your monitoring.