My Journal

So I'm forced to learn and install Windows Server 2012 R2, quickly. Thanks to some hacker's ransomware for my school. It happened once before, but files were encrypted through a regular user's account. The server's system weren't affected. But this time, they are.

This happened right after I restricted inbound RDP to certain IPs in the firewall. So the hack must have gotten in from one of the networked machines, which I did not block. With Win Server 2018, it seems that there was no way to monitor this type of attack.

Hopefully, Windows Server 2012 R2 can do a better job. Had to put this on a 64-bit machine. A few changes for the users: be serious about hard to guess passwords.

Something that always bugs me is this CAL licensing. I think now I understood a bit: A CAL (license) is what allows ONE user to logon to the server (locally). Remotely, you need an RDS CAL (on top of the one CAL), because RDS CAL is only for the user's remote session while the CAL is what allows the server to allow the user to logon on it. Of course, RDS CAL is also differentiated between RDS user CAL and RDS device CAL. What was described above is for RDS user CAL. For the Device CAL, it just means instead of the user being licensed, it's the user's device that's been licensed (so I guess it doesn't matter who logs in as long as it's the licensed device).

Somehow it took me a while to find out information about purchasing such licenses. I think Windows Server has its own license (around $100 for now). But for a Windows Server 2012 R2 10 User CAL, it's around $130 now, while 10 RDS User CAL costs about $370. They are apparently valid for a lifetime.

That means, from square one, a Windows Server 2012 R2 with 10 RDS user licenses costs about: $100 + $130 + $370 = $600. 10 is enough for my school for now, but 20 would be preferred, which would cost $1,100 total.

Nevertheless, there are some sites that claim that we can reset the grace period of 120 days of Unlimited RDS CAL. One is to delete a value in the registry:
Delete the REG_BINARY (i.e. L$RTMTIMEBOM****) in: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod

To delete the key you must take ownership and give admin users full control.

After a restart of the server RDS will reset the grace period to 120 days. This has worked for me.

Another is to run

slmgr /rearm

in powershell as administrator. In case the previous method fails.

To find out how many grace period is left, run powershell as administrator and use this command:

(Invoke-WmiMethod -PATH (gwmi -namespace root\cimv2\terminalservices -class win32_terminalservicesetting).__PATH -name GetGracePeriodDays).daysleft

As for Windows Server 2012 R2 itself, there's also a way to keep reactivating it:

1. Get the right product key from the official article of Microsoft.The KMS Client Setup Key of WS 2016 Standard is “WC2BQ-8NRM3-FDDYY-2BFGV-KHKQY”. I will use it in the next step.
   
2. Install the key on your server.To open command prompt, click on the Windows button, search for “cmd” and run the command prompt as administrator. Then, enter “slmgr /ipk CLIENTKEY” in the command window.
   Note: each command is followed by hitting Enter.
   
   
3. Set the KMS server.Enter “slmgr /skms kms8.msguides.com” in the window.
   
4. Activate the KMS client key.Finally, use the command “/ato” to activate your Windows.

I tried the KMS product key (D2N9P-3P6X9-2R39C-7RTCD-MDVJX) for my 2012 R2 Standard edition and it seems to work (for now).

So lately, many low lives from the third world countries love to try RDP into a computer by bruteforce since it's likely that the security against such tactics isn't strong enough in RDP.

I've met a couple of such attacks. They found a password that works by bruteforce, RDP in, encrypt all documents and then left a window message demanding for ransom in bitcoins costing at least $8k.

So, I finally decided to put some restriction on this. Took a while to get this, which was why I delayed until now. Though it's not hard. The idea is to grant only certain IPs to RDP in.

Solution:

1. Go to the control panel->Administrative Tools
2. Windows Firewall with Advanced Settings
3. Inbound Rules
4. Remote Desktop (TCP-In)
5. Go to the Properties->Scope tab
6. Add the IP (or IP range) in the Remote IP addresses section

I've also learned that this Windows Firewalls settings is required at a domain level, not just (or quite) private or public.

• Open Control Panel -> Windows Defender Firewall
• Click Advanced settings
• Adjust the default action for each profile:

After setting several IP ranges, tested, awesome!

A netstat -an test also show that some IPs that were trying the 3389 port got disconnected/disappeared once I applied the inbound rules with Domain Profile Firewall State "ON".