Saturday, 26 September 2020

Adding VLANs to OpenWRT

Adding VLANs to OpenWRT.md

Adding VLANs to a hacked OpenWRT router

Technicolor MediaAccess TG589vac

TG589vac Router

Warning: Incorrectly modifying the /etc/config/network file can cause switch/router inoperabilty, it could brick the device or cause it to lose network connectivity to it’s management interface. Follow these steps only with full knowledge that you could destroy your router or switch. I accept no responsibility!

I inherited one of these routers from a previous ISP and bought another from ebay since they make pretty competent 4-port gigabit switches once the firmware has been rooted. I have a guide to root your TG589vac here. Since setting them up as my home lab switches, I now have a requirement to implement VLANs on my network for segmentation and to make things tidyer on my virtualisation hosts.

Since these routers are running OpenWRT then adding VLANs to them is fairly straight forward. Log into the router as root and modify the network config file with vi /etc/config/network

The interesting section of this file is here:

config switch_vlan 'lan_switch'
	option ports '1* 2* 3* 4* 8t'
	option device 'bcmsw'
	option vlan '1'
config switch_vlan 'lan_switch'
	option ports '1* 2* 4t 8t'
	option device 'bcmsw'
	option vlan '1'

config switch_vlan 'lan_switch_vlan5'
	option ports '3* 4t 8t'
	option device 'bcmsw'
	option vlan '5'

Notice that port 3 was removed and port 4 was switched to tagged on VLAN id 1, then VLAN id 5 has been configured on port 3 untagged and port 4 tagged. I’m unsure of the significace of port 8t but in my case it works with the port included in all additional VLANs.

* - denotes untagged
t - denotes tagged

Warning: DO NOT change the name of the vlan ‘lan_switch’ doing so caused a segfault when reloading the network on my switch and soft-bricked it. The switch was left restarting the network over and over. After much trial and error, I managed to factory reset it once all physical network ports were unplugged.

Once you have made your edits, restart the network with /etc/init.d/network reload or service network reload depending on the OpenWRT version.

root@dsldevice:~# /etc/init.d/network reload  
Success  
JUMBO_PORT_MASK:0x000001FF  
GPHY_0 port accepts jumbo frames.  
GPHY_1 port accepts jumbo frames.  
GMII_1 port accepts jumbo frames.  
GMII_2 port accepts jumbo frames.  
GPON_SERDES port accepts jumbo frames.  
MOCA port accepts jumbo frames.  
USB port accepts jumbo frames.  
GPON port accepts jumbo frames.  
MIPS port accepts jumbo frames.  
Success  
Success  
CDK_E_PORT  
CDK_E_PORT

If you happen to do this and find out you cannot get multicast working on your new VLANs, check out this post.

Written with StackEdit.

Saturday, 19 September 2020

Windows Process Command Line Logging

Windows Process Command Line Logging

Windows Process Command Line Logging

Introduction

There are many reasons to gather process launch information in a Windows environment. Troubleshooting, Security forensics, Performance Analysis to name a few. By default, Windows does not log process launch information so it will need to be configured using local or group policy.

There are some security consequences of enabling process command line logging. Some commands, including some legacy AD commands require using a password or secret key as a parameter. Ideally we wouldn’t want these secrets appearing in logs, unfortunately the the only way to exclude them is to disable command line logging which substantially reduces the usefulness of enabling process logging in the first place.

Reading the logs requires local administrator rights on the system, however this could lead to privilege escalation; for instance if a logged command line included a Domain Admin password. The usefulness in forensics though, may be more benefit than the risk of having secrets in the Windows Event log. It may be prudent to configure log forwarding to a hardened server and regular log rotation on client and server systems.

Required Policy Settings

Warning: Enabling the Audit: Force audit policy subcategory settings policy will override any basic policy settings that are configured on the system. These should be translated to the equivalent advanced audit settings if they are required.

In order for Windows to log event ID 4688 so that you can see Windows process creation events and their command lines, there are several policy settings to configure:

Enable Audit: Force audit policy subcategory settings policy in Computer Configuration\Policies\Windows Settings\Local Policies\Security Options

Enable the Audit Process Creation policy in Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Configuration\Audit Policies\Detailed Tracking

Enable the Include command line in process creation events setting in Administrative Templates\System\Audit Process Creation

Audit: Force audit policy subcategory settings
Force sub policy

Audit Process Creation
Audit Process Creation

Include command line in process creation events
Include Command Line

If using Group Policy, once the policy is saved, run gpupdate /force on the targeted system. Once applied, running auditpol /get /category:* should show the appropriate audit policies being applied.

Troubleshooting

While deploying this group policy, I noticed that Process Creation was not being set when running auditpol /get /category:*. After enabling an unrelated advanced audit policy such as Account Lockout in the Logon/Logoff category, the Process Creation policy was applied. I was then able to remove Account Lockout while still keeping Process Creation. I’m not exactly sure why this issue ocurred, but I think it happened due to the order the policy elements were applied.

No Auditing Success and Failure

Reviewing the Windows Event Log

Once the above policy and audit settings are in place then the system will begin logging event ID 4866 in the System event log

Windows 4688

Gathering Process History for a machine in PowerShell

Looking at windows event logs can be time consuming and tedious, so here is a short PowerShell script to parse the event log on a target machine for recent commands:

Script Output:

Script Output

Extending with SysInternals Sysmon

While logging process creation events with the full command line is a powerful forensic tool, there is much more detailed logging available in SysInternals Sysmon. Next time I will be installing and configuring Sysmon to generate more verbose forensic logs including process creation and termination, generation of suspicious file modification and deletion logs, Registry modification and even WMI event logging.

Gathering Domain Controller Audit Policy

I’ve also written a quick script to gather the audit policy for all Domain Controllers in the domain. You can find it here.

Written with StackEdit.

Quick Script: DC Audit Policy

Quick Script: DC Audit Policy

Quick Script: Check all Domain Controllers for Audit Policy Settings

Introduction

Here’s a quick script to gather the detailed audit policy for all Domain Controllers in the domain. This is useful if you have domain controllers in different OUs with different policies applied. It will give a quick overview of each audit policy on each machine and since it’s in a GridView it’s easy to filter and sort the list so you can check a single policy against all your DCs.

The Script

Written with StackEdit.

Vulnhub Writeup: Glasgow Smile

Vulnhub - Glasgow Smile Vulnhub Writeup - Glasgow Smile 1.1 Description Title: Glasgow Smile Users: 5 Difficulty ...