{"id":277,"date":"2022-02-20T09:48:31","date_gmt":"2022-02-20T09:48:31","guid":{"rendered":"https:\/\/www.cybersecuritynotepad.com\/?p=277"},"modified":"2022-02-20T10:05:38","modified_gmt":"2022-02-20T10:05:38","slug":"targeted-process-injection-linux","status":"publish","type":"post","link":"https:\/\/www.cybersecuritynotepad.com\/index.php\/2022\/02\/20\/targeted-process-injection-linux\/","title":{"rendered":"Targeted process injection – Linux"},"content":{"rendered":"\n
In this post I will cover briefly how to modify the memory of running process in real-time. The example chosen for this demonstration is simple. The main purpose is to show the approach rather than make it look sophisticated. However, you can take it as far as you wish, depending on your objectives. In future posts, I will cover additional scenarios and also will add more weaponised examples.<\/p>\n\n\n\n
\n\n\n\n
One important question that needs answering is why would somebody want to directly inject information\/data into the running process. Imagine the following scenario, post compromise you have SSH access to the Linux server. At this stage you can escalate privileges or stay on the system as low privileged user. For privilege escalation traditional methods such as misconfigured permissions, cron jobs, unpatched software and other issues could be used. Those techniques and methods are well known to offensive, defensive and forensic teams. As soon as you follow the usual script, your presence will be detected and the access may be removed. In those types of scenarios, you can be creative and that’s when this technique may come in handy. <\/p>\n\n\n\n
\n\n\n\n
For the demo, I used the “nano” text editor. The user “user2” who is a standard system user with limited privileges opened a text file “myfile.txt” and started typing text into the file just like a typical user would. <\/p>\n\n\n\n
<\/figure><\/div>\n\n\n\n
As you can see the text “CHANGEME” text appears in the left terminal and in the right terminal the process 1227 is attached to the “gdb” debugger. <\/p>\n\n\n\n
Next we identify the area where the text is in the process memory. In this case it is on the heap. <\/p>\n\n\n\n<\/figure>\n\n\n\n
We are only interested in the heap because this is where the text is that the user “user2” wrote within “nano” text editor. <\/p>\n\n\n\n
heap start address 0x56399993e000 \nheap end address 0x563999a04000<\/code><\/pre>\n\n\n\n
When searching memory it is never easy to find specific information without some trial and error approach. In this case, after spending a while examining the memory I knew immediately where I should look for the desired information. I simplified the process for you so that you can see the results rather than trying to find the needle in the haystack. As you can see now, I found the memory address where the string “CHANGEME” sits and replaced it with the string “LIVEDEMO”. After completing that task I detached the process 1227 from the debugger. <\/p>\n\n\n\n
Now you can see above that in the left terminal, the “CHANGEME” string is still there as before. It looks to the user “user2” as if nothing has changed because the text has not been refreshed. However, in memory the change has been made and, if the user saved the file or even copied the first line “CHANGEME” into the clipboard they would get “LIVEDEMO” string when pasting from the clipboard or saving the file “myfile.txt”. I have added short descriptions to the left terminal so that you can see what happened. <\/p>\n\n\n\n<\/figure>\n\n\n\n
The final screenshot shows that even if on user’s screen nothing changes, the memory address shown below has been modified:<\/p>\n\n\n\n
0x5639999dea10 <\/code><\/pre>\n\n\n\n
The above address no longer stored the string “CHANGEME” but “LIVEDEMO”. After saving the text file and reopening it the user “user2” will see the modified string “LIVEDEMO” confirming that the injection into the live memory within the heap space has been successful. <\/p>\n\n\n\n<\/figure>\n\n\n\n
As you can see, it is not that difficult to get it done. In fact, it is easier than you may think. Imagine what would happen, if you changed just one byte in the right place and at the right time to disable security controls. Going one step further, you can execute the code without leaving forensic artifacts, as long as you know what you are doing. <\/p>\n","protected":false},"excerpt":{"rendered":"
![\"\"](\"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2022\/02\/d1c-1-1024x490.png\")
<\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2022\/02\/d2c-1024x486.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2022\/02\/d3c-1024x494.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2022\/02\/d4c-1024x496.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.cybersecuritynotepad.com\/wp-content\/uploads\/2022\/02\/d6c-1024x506.png\")
<\/figure>\n\n\n\n